Добро пожаловать в Логово Силвервинга

Графика

Движок создается для 2D спрайтовых игр. Не планируется ни попиксельного рисования, ни векторных операций, ни шейдеров, ни 3D преобразований. Простое рисование картинок на экране. Этого уже достаточно для большого количества игр, но самое важное -- достаточно для большинства наших игр.

Дополнительно: будет интересно добавить поддержку произвольных трансформаций спрайтов при помощи матриц. Однако это не требуется для нашей первой игры, поэтому я вряд ли буду это делать для первой версии.

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

Движок будет обрабатывать все рисуемое на экране как слой. Для первой версии я планирую следующие типы слоев:

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

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

Поскольку наши игры в большинстве своем будут использовать пиксельную графику, нам потребуется и масштабирование. Использование слоев позволит сделать это прозрачно. Слои могут масштабироваться по-разному в зависимости от типа слоя.

Я скорее всего ограничу максимальное разрешение чем-то очень большим просто для надежности. Минимальное разрешение будет 320x200.

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

Как я объяснил выше, мы жестко ограничим поддерживаемые форматы файлов. Для графики это будут PCX (сжатый и несжатый) и PNG (сжатый). Для наших игр мы, скорее всего, будем использовать PNG, однако несжатый PCX будет загружаться заметно быстрее на слабых компьютерах.

Звук

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

И вновь переносимость требует от нас определить поддерживаемые форматы:

• несжатое PCM аудио с 8 или 16 разрядами глубины и частотой дискретизации 22050 или 44100Гц; формат контейнера -- только Wav;
• сжатое Vorbis аудио с 8 или 16 разрядами глубины и частотой дискретизации 22050 или 44100Гц; формат контейнера -- только Ogg;
• для музыки мы также рассматриваем MIDI и трекерные форматы.

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

Ввод

Здесь мы не можем позволить себе компромиссов. Нам потребуется поддержка всех основных способов ввода: клавиатура, мышь и игровые контроллеры. Поскольку поведение ввода сильно зависит от игры, мы не будем навязывать никаких переопределений управления на уровне движка. Вместо этого мы сделаем опциональную и настраиваемую библиотеку для этой цели. Разумеется, мы, прежде всего, оптимизируем эту библиотеку под наши цели.

Данные

Обычно игровые движки реализуют виртуальные файловые системы для прозрачной работы с файлами как из ресурсных архивов, так и из локальной файловой системы. Этот подход работует хорошо, однако имеет важный недостаток, связанный с тем, что пути и файловые системы в общем случае не переносимы: некоторые файловые системы чувствительны к регистру, другие нет; ограничения на длину имени файла, количество файлов в папке, допустимые символы и другие ограничения также зависят от файловой системы. Все это не только вынуждает разработчика постоянно держать в уме ограничения всех поддерживаемых систем, но и затрудняет портирование на новые системы (ведь их ограничения не будут учтены ранее написанными играми). Более того, это делает крайне простым написание игр, которые работают только на системах совместимых с используемой разработчиком.

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

Чтобы решить это потребуется:

• найти или реализовать формат архива, подходящий как для чтения, так и для записи данных (или можно попробовать использовать для сохранения игр базу SQLite. Недостатком этого будет необходимость владения языком SQL для работы с сохранениями и настройками, а также дополнительная зависимость);
• реализовать дополнительный API для выбора файлов из файловой системы. Это потребует некоторого платформо-зависимого UI, однако скорее всего реализация этой функции нам необходима;
• реализовать отладочный режим, который позволит загружать файлы непосредственно из файловой системы (это необходимо для избежания перепаковки после каждого изменения).

Среда исполнения

Для создания по-настоящему платформо-независимой игры, она должна выполняться в виртуальной машине. Это может быть интерпретируемый язык, работающая с байт-кодом виртуальная машина или даже эмулятор настоящего процессора. Я сильно склоняюсь к использованию Lua для этой цели из-за его высокой переносимости и достойной производительности. Большинство прототипов движка также используют Lua. Однако есть несколько альтернатив, которые я также рассматриваю:

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

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