Довольно большой и сложной темой оказался принцип вывода игровых объектов при различных разрешениях. Первым порывом было, разумеется, сделать фиксированное разрешение (или набор из нескольких) и реализовать для каждого из них отдельный вариант отрисовки. При беглом взгляде на самые популярные среди геймеров разрешения были сделаны выводы о популярности соотношений сторон:
16:9
5:4
16:10
4:3
Вам нравится играть на геймпаде? Согласитесь, что откинуться в кресле и наслаждаться игрой на мышке с клавиатурой не очень-то получится В подобном случае геймпад подходит как нельзя лучше. Поэтому мы не смогли пройти мимо возможности добавить его поддержку в игре.
Перед началом разработки мы вспомнили и проанализировали все неудобства которые встречали в играх, а именно:
Учитывая данные проблемы мы решили что игра будет определять на каком устройстве играет человек и автоматически активировать именно его. Если игрок взял в руки другой манипулятор, то игра сразу переключится на него и перестанет использовать другой. Разумеется, обратный путь так же прост.
Зная о том, какое устройство ввода используется, система отображает подсказки под него и отключает вибрации геймпада, если он не используется.
Решающим фактором для нас оказалась система, настолько прозрачно использующая любой манипулятор, что нам (разработчикам) абсолютно неизвестно с каким именно устройством мы взаимодействуем. Это позволяет добиться огромной универсальности и простоты добавления новых устройств. Таких как руль, джойстик и т.п.
Так, как спецэффекты это явно то, чем мне нравится заниматься, я сделал такой вот объект для фона игры. Планету. Красную, как Марс. Немного необитаемую и неживую.
Так как наша игра полностью 2д, то и планета абсолютно плоская. Добиться этого удалось довольно-таки нехитрым шейдером. По большому счету это уже известный DuDv. Почитать про него можно в старом блоге.
Для генерации планеты пришлось воспользоваться текстурой планеты в разрешении 1024х512 и аналогичного размера текстурой облаков. Также для искажения понадобилась DuDv-карта размером 512х512, атмосфера и затенение.
При создании модуля локализации решили не использовать стандартные средства, а изобрести собственный велосипед. К реализации было два основных требования. Во-первых, чтобы имя или название (Label), которое требует локализации, присваивалось объекту один раз при его создании, а затем менялось на лету. А во-вторых, чтобы это было не затратно для производительности.
Именно второе условие по сути не дало использовать словари или методы, которые легко реализовали бы первое условие. Таким образом, наиболее подходящим решением нам показалось использовать в качестве локализованной строки указатель на строку PWideChar. Предполагалось, что отображаемые названия будут ссылаться на эти указатели, а данные по адресам указателей меняться, когда меняется язык.
Однако, в данной реализации был один существенный минус. Память под локализованные строки пришлось бы выделять заранее и строго фиксированную. То есть, какая-нибудь длинная строка из файла локализации тупо не влезла бы в отведенную ей память. Единственным выходом из данной ситуации было ввести промежуточное звено — указатель на указатель. Адреса указателей на указатели (LocalizedStrings) остаются неизменными, память под них заранее известна и зафиксирована. А вот значения по адресам локализованных строк каждый раз при загрузке нового языка будут меняться с выделением новой памяти и высвобождением старой.
