Горячая линия: игрострой
24 часа в сутки вопросы по созданию, модифицированию и вскрытию игр принимаются по адресу gamedev@igromania.ru или по SMS на короткий номер 1121 с префиксом dev (то есть в начале сообщения печатаете слово dev, а затем, через пробел, сам вопрос). Стоимость каждого SMS — 10 центов. Обратите внимание, что ответы на вопросы даются только в журнале.
В редакторе TES 4: Oblivion я наткнулся на пункт меню World\Run Havok Sim. Не могли бы вы рассказать, что это за инструмент и для чего он нужен?
Данная функция предназначена для теста физики игрового мира. Допустим, создали вы оружие или модель персонажа в 3DS Max и импортировали объект в редактор. После этого необходимо убедиться, будет ли новый предмет вести себя в соответствии со всеми законами физики TES 4: Oblivion. Помещаете новый предмет на карту (в любое место — главное, чтобы оно было немного над поверхностью земли) и активируете модуль Havok Sim. Если в модели присутствуют все необходимые компоненты, то вещица должна будет упасть на землю. Если же она так и останется висеть в воздухе, то где-то вы напортачили и задали неверные атрибуты физики.
Я внимательно изучил статью по вскрытию Heroes of Might and Magic 5, но не нашел там ответа на один очень важный вопрос. Можно ли как-то методом вскрытия увеличить расстояние, которое герои преодолевают за один ход? Карта, которую я сделал для игры, очень большая, и если длина хода будет стандартной, герои станут ползать от одного края к другому часами.
Никаких проблем. Увеличить длину хода совсем несложно. В этом вам поможет файл DefaultStats.xdb , находящийся в директории GameMechanics\RPGStats (архив data.pak ). Править его лучше всего в обычном «Блокноте». В данном случае нам будет интересен раздел Adventure.
Первый параметр этого блока — BaseHeroMovement — определяет базовое расстояние, которое герой способен пройти за ход. Обратите внимание на то, что здесь не учитываются штрафы за хождение по пересеченной местности и всевозможные бонусы (в частности, степень развитости у героя логистики и нахождения пути). Этому атрибуту следует поставить значение повыше — в районе 2700 — 3500.
Желательно также изучить группу характеристик, задающих размер разовых бонусов к дальности хода при посещении различных строений. Речь идет о следующих настройках: VisitFountainOfYouthMovementBonus — прибавка к ходу за обращение к фонтану молодости, VisitRallyFlagMovementBonus — к восстанавливающему флагу, VisitOasisMovementBonus — к оазису, VisitStablesMovementBonus — к конюшне. Оптимальным вариантом будет поставить этим показателям значения примерно в следующих пределах: 500 — 600 , 450 — 550 , 900 — 1000 , 700 — 750. Аналогичный атрибут имеется для путешествия по морю — LighthouseMaxSeaMovementBonus. Ему лучше присвоить значение 600 — 700.
Что касается конюшни, то за нее отвечает атрибут ForWeekStablesMaxLandMovementBonus. Он определяет размер ежедневной надбавки к скорости героя до конца недели (если строение посещалось). Впишите сюда число 700 (или даже чуть выше).
Здесь же вы найдете параметр BaseHeroLookRange (регулирует базовое поле зрения героя). Раз уж мы развили в героях навыки путешественника, неплохо бы еще сделать их более зоркими. Для этого придайте характеристике значение в интервале 15—20. После всех этих изменений бонусы к скорости героев станут куда ощутимее. Да и вообще ваш персонаж (как, впрочем, и ваши соперники) будет готов к преодолению огромных расстояний за короткое время.
В корневом каталоге с Titan Quest, помимо файлов редактора, о которых вы рассказывали в статье «Титанический квестострой», я обнаружил несколько компиляторов: MapCompiler, ModelCompiler и ряд других. Почему про них нигде не было ни малейшего упоминания?
Описанные вами приложения предназначены для перевода исходных файлов уровня в формат игры. Но зачем делать это вручную, если все действия за нас делает утилита Art Manager? То есть опосредованную работу с компиляторами мы на самом деле описали. Случаи, когда нужно обратиться к ним напрямую, минуя Art Manager, мы себе слабо представляем. Куда проще нажать пару кнопок, чем писать длинные строки кода в командной строке.
Вопрос месяца
Привет, «Игромания». Я пишу текстовую RPG (графика будет только в виде фонов и кукол героев), движок я сделал такой, что каждый диалог подгружается из отдельного файла. То есть файлов этих очень много, несколько тысяч, а будет еще больше. Сейчас уже готово более половины игры, и неожиданно я задумался вот над каким вопросом. Весь текст я храню в кодировке Windows 1251, знакомый программист сказал, что лучше бы я сохранил все диалоги в UTF-8, потому что у него больше возможностей. Это действительно так? У меня действительно не все символы получается сохранить в Windows 1251, но, возможно, есть еще какие-то нюансы?
Друг-программист во многом прав. Кодировки Windows-1251 , KOI8-R и им подобные устарели, хотя их до сих пор повсеместно используют в веб-программировании, да и в txt-файлах к играм они частенько встречаются. Основной недостаток этих реликтов в том, что они могут отобразить на экране только 256 символов, тогда как UTF-8 поддерживает всю символику международного стандарта Unicode (все подробности о нем можно узнать на официальном сайте — www.unicode.org). А это более ста тысяч различных символов. Тут вам и дроби, и товарные знаки, и математические обозначения, и лигатуры. Главное же — в Unicode зашиты символы практически всех алфавитов.
На практике это работает следующим образом. Есть файл, из которого движок подгружает текст в вашу игру. Открываете вы таблицу символов в Windows или в Mac, если разработка игры ведется на нем (платформа не имеет значения, ведь стандарт общий), копируете из нее любой значок и вставляете прямо в ваш документ. И если это документ в формате UTF-8 и движок игры его понимает, то символ в игре будет отображен так же, как вы видите его в таблице.
В случае же с кодировками первой волны (KOI8-R, Windows-1251) большинство символов вам придется шифровать. Даже обычное тире не поставишь, придется вписывать специальный ключ (например, & mdash;). А если нужно не тире, а дефис? Извольте вписать ключ & #x2011;. И смотрите не перепутайте! Ведь для движка дефис и тире это совершенно разные символы. И так на каждом шагу. Как только вам понадобился нестандартный символ, вы вынуждены использовать ключи. А в случае с UTF-8 все просто: скопировал — и символ сразу появился в игре.
Некоторые начинающие программисты утверждают, что ключи — это, мол, круто, здорово и только так и нужно. Разумеется, это не так. Ключи были созданы исключительно потому, что Windows-1251 и ей подобные кодировки поддерживали слишком мало знаков (256), остальное приходилось шифровать. Сейчас, когда есть Unicode, необходимость в таких заморочках отпала.
Программисты старой школы иногда кидают в огород UTF-8 еще несколько комов грязи. Говорят, текстовые файлы в этой кодировке занимают больше места, что если игра разрабатывается для интернета, то не все браузеры адекватно обрабатывают UTF-8, что если кодировка используется на веб-страницах, то поисковики ее не видят…
Всему этому тоже не верьте. Подобные обвинения были правомерны еще года три-четыре назад, но не сейчас. Все современные интернет-браузеры отлично распознают UTF-8 (только надо не забывать указывать в тегах, каким способом закодирована ваша страничка, иначе браузер и Windows-1251 может не обнаружить), поисковики тоже отлично эту кодировку видят. А что касается объема файлов, то да, упрек оправдан, на кодировку большинства символов в UTF-8 уходит больше бит, чем, скажем, в KOI8-R. Но это закономерно: одно дело зашифровать 256 символов, совсем другое — 100 000. Обратите внимание, буквы английского алфавита занимают тот же объем, разница есть в русском и других языках. Если же сравнивать кодировку спецсимволов, то UTF-8 оказывается в выигрышном положении, потому что не приходится использовать ключи в духе ‑ (посчитайте-ка, сколько тут символов нужно закодировать).
И в завершение один очень важный момент. UTF-8, как уже было сказано выше, работает со стандартом Unicode, который, в свою очередь, поддерживает кодирование более сотни тысяч символов. Но это вовсе не значит, что на любом компьютере все эти символы будут правильно отображаться. Запомните: кодировка — это интерпретация кода компьютером, а отображение — это выведение на экран определенного шрифта, каждый символ которого может соответствовать, а может и не соответствовать кодировке.
То есть если вы хотите вывести на экран изображение, скажем, какой-нибудь скандинавской руны, то вам недостаточно закодировать ее при помощи UTF-8. Необходимо, чтобы на компьютере пользователя был установлен шрифт, содержащий символ руны (сопоставленный Unicode-кодировке). Если шрифта нет, то либо игра вылетит с ошибкой, либо будет отображен неверный символ.
Даже если при разработке у вас в игре все отображается верно, не поленитесь и зашейте все шрифты в движок. У вас-то они из системной папки подгружаются, а у игрока могут быть вовсе не установлены. Поэтому еще раз: все шрифты должны быть в движке, никаких обращений к внешним TTF-файлам.