Компания
89,30
рейтинг
9 июля 2014 в 17:32

Разработка → GUI в игре World of Tanks. Часть вторая: обзор структуры GUI и планы на будущее

image

Сегодня мы продолжаем начатый неделю назад рассказ об интерфейсе игры World of Tanks.

Текущее состояние проекта

Освежим информацию из первой части статьи.

Сейчас для рендеринга GUI в проекте используется технология Autodesk Scaleform, которая позволяет использовать Flash как среду разработки.

Кто знаком с Flash, тот знает, что языком программирования в этой среде является ActionScript. У этого языка есть несколько версий, но самые широко используемые — ActionScript2 (AS2) и ActionScript3 (AS3).
В нашем проекте на текущий момент используются обе версии. Обусловлено это тем, что разработка начиналась на AS2, так как Scaleform на тот момент еще не поддерживал AS3. Со временем, когда поддержка AS3 в Scaleform появилась и ее реализация стала достаточно надежной, начался перевод сервисных (не боевых) интерфейсов на AS3.

Почему переход на AS3 начался с миграции на него именно сервисных интерфейсов? Все очень просто. Бодрое танковое рубилово — это наше все. Любые помехи, лаги или баги в боевом интерфейсе могут испортить ощущения пользователя в процессе игры. На такой риск мы пойти не могли и начали миграцию с менее требовательной с точки зрения ресурсов и не такой критичной для игрового процесса части. Такой подход полностью себя оправдал. Мы наткнулись на проблемы с производительностью и потреблением памяти. Большую часть из них мы решили до релиза обновленного ангара, какие-то отлавливали и исправляли уже в продакшене, опираясь на баг-репорты от игроков. Обошлось без серьезных проколов, что не может не радовать.

В предыдущей статье я приводил список проблем, с которыми нам приходилось жить в AS2. Освежу этот список:

  • проблемы с различными версиями кода в разных SWF-файлах;
  • проблема коммуникации Flash <—> Python;
  • отсутствие стандартизации и унификации в коде;
  • отсутствие четких правил и процедур по добавлению нового функционала;
  • отсутствие автоматизации сборки проекта.

Эти проблемы вносили свой немалый вклад в трудозатратность при добавлении нового функционала в проект, и это еще одна причина, почему переход на AS3 начали с сервисных интерфейсов. С точки зрения GUI, ангар — часть проекта с наибольшей концентрацией нового функционала на релиз, и, соответственно, наиболее затратная по человеческим ресурсам. В свою очередь, боевой интерфейс уже работает на AS2, обновляется не так часто и больших нареканий не вызывает. Зачем ломать то, что и так работает?

Обзор архитектуры и процесса разработки

Но не Flash-ем единым живет GUI-разработчик WoT. В качестве скриптового языка в проекте используется Python. Всю красоту, которую мы сделали во Flash, нужно подключить в игре, наполнить данными, обработать и транслировать пользовательский ввод в реальные действия в игре. Все это как раз и делается в Python.

Вот упрощенная схема основных элементов GUI в клиенте:

image

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

AS2 и его взаимодействие с Python

При входе в бой начинается загрузка battle.swf. В этом файле содержатся практически все основные элементы боевого интерфейса (HUD): списки команд, чат, панель состояния танка, мини-карта, панель расходников и т. д.

Практически за каждый элемент, присутствующий в battle.swf, отвечает один из классов в Battle.py. При завершении загрузки содержимое файла растягивается на весь viewport игрового клиента и отрисовывается поверх 3D-сцены. Кроме battle.swf также загружаются SWF-файлы для отображения маркеров и прицелов. Они помещаются под battle.swf для того, чтобы маркеры и прицелы не накладывались на элементы HUD, а прятались под ними.

Также для систем с несколькими мониторами SWF-файлы с прицелами и маркерами растягиваются на все мониторы, а battle.swf отрисовывается только на главном мониторе (чтобы HUD не разлетелся по разным углам этих мониторов и осталась возможность адекватно читать боевую информацию).

За состоянием маркеров и прицелов следит Python. В нем обрабатываются игровые события и данные, создаются и уничтожаются маркеры и прицелы. Для каждого типа прицелов есть свой Python-класс. За маркерами следит VehicleMarkersManager. За расположение маркеров и прицелов на экране отвечает клиентский C++ код.

Для коммуникации Flash и Python в бою используются два подхода:

1) Наиболее частый — передача данных массивом скалярных данных через API, предоставляемое в Scaleform. В предыдущей статье я описал этот метод и объяснял его недостатки (неудобно читать код, рефакторить и поддерживать).

2) Второй подход — Direct Access API (DAAPI). О нем я только упоминал, а теперь расскажу подробнее.

У этого подхода есть два основных преимущества: простота и скорость работы.

Простота заключается в том, что передавать сложные объекты в обе стороны можно не думая о сериализации/десериализации — все происходит автоматически в C++. Скорость работы достигается за счет того, что вызовы методов в обе стороны происходят «напрямую». То есть, имея ссылку на Flash-объект в Python, можно вызвать его метод и передать в него аргументы так, как будто это Python-объект. Без использования DAAPI вызов методов происходит по указанию пути к Flash-объекту в дереве визуальных компонентов и поиску этого компонента в иерархии, что дорого.

Кроме этих явных плюсов есть еще один, но очень важный — можно назначить Python-объект в качестве обработчика для Flash-объекта.

Нарисую и поясню, что происходит, по шагам.

image

  • Во Flash создаем класс с объявлением публичных полей с типом Function. Значения этих полей не инициализируем, т. е. они == null.
  • В Python создаем класс с реализацией для этих методов. Именование методов должно совпадать с именованием полей во Flash-классе.
  • Создаем экземпляры этих классов во Flash и Python.
  • Передаем ссылку на Flash-экземпляр в Python.
  • Назначаем экземпляр Python-класса как обработчик для экземпляра Flash-класса (устанавливаем DAAPI соединение).
  • Вызываем метод из первого пункта во Flash-классе.
  • Благодаря DAAPI происходит вызов метода, реализованного в Python. Причем для Flash это выглядит как вызов обычного метода во Flash. В качестве параметров могут выступать как скалярные типы данных, так и сложные объекты.

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

Как устроена AS3 часть проекта

В первую очередь, нужно сказать о том, что сборка проекта происходит с помощью Apache Maven и Apache Ant. Логически проект разбит на несколько слоев:
  • Common — SWC-библиотека с набором общих файлов, используемых в проекте. Сюда входит:
    — библиотека Scaleform CLIK (набор UI-компонентов и менеджеров);
    — базовые классы и интерфейсы инфраструктурной части проекта;
    — код сторонних библиотек, используемых в проекте.
  • GUI — SWC-библиотека, в которой собран код всех вьюшек, окошек и других визуальных объектов.
  • App — содержит имплементации всех менеджеров и инфраструктурных классов. Сборка этого проекта дает на выходе application.swf.

Точкой входа в AS3-приложение является application.swf, содержащий класс net.wg.app.impl.Application. Этот файл всегда загружается при старте клиента. Он решает три основных задачи:

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

У класса Application из AS3 есть вторая половинка в Python — класс AppEntry. Задачи этого класса:

  • cоздание и инициализация инфраструктурных частей проекта в Python (все абсолютно симметрично первому пункту из AS3 части);
  • загрузка конфигурации, описывающей взаимосвязи между AS3 и Python частями проекта (подробнее об этом буквально через несколько абзацев);
  • инициализация DAAPI-соединения для самого Application и всех инфраструктурных классов.

В процессе сборки Common- и GUI-библиотек мы используем YAML для генерации кода. Вот список задач, которые мы решаем, используя YAML:

  • описания интерфейсов взаимодействия Flash- и Python-половинок одного модуля (модулем можно считать вьюшку или менеджер);
  • создания классов констант, общих для Flash и Python;
  • создания классов констант для локализационных сообщений;
  • создания классов констант для изображений, подгружаемых на рантайме;
  • создания ClassLoader — класса, содержащего импорты и ссылки на все используемые в приложении AS3 классы. ClassLoader используется для упаковывания всего кода проекта в application.swf.

Любой класс в AS3 (будь то класс, отвечающий за работу какой-то вьюшки, или менеджер без визуального представления), которому нужна коммуникация с Python, должен быть создан с помощью описания в YAML. Давайте рассмотрим это на примере окна послебоевой статистики:

BattleResultsMeta.yaml

!net.wg.WoT.models.DAAPIModel
type: window									# определяет базовый класс для Flash классов
python:										# перечень Python методов, доступных для  вызова из Flash
  - BattleResultsMetaPy: [ eventBus : net.wg.py.app.EventBusPy ] 		# конструктор
    constructor: eventBus  
  - saveSorting: [ iconType : String , sortDirection : String , bonusType : int ] # сохраняет предпочтения по сортировке
  - showEventsWindow: [ questID : String ] 					# вызвает показ окна боевых задач
flash:										# перечень Flash методов, доступных для вызова из Python
  - BattleResultsMeta: [ ]							# конструктор
    constructor:
  - as_setData: [data : Object]							# передача готовых данных с результатами боя во Flash

После обработки этого YAML-файла в ходе сборки проекта сгенерируется следующий набор классов и интерфейсов:

BattleResultsMeta — базовый Python-класс. В нем объявлен набор всех методов из python-секции YAML для их последующей перегрузки в классе-наследнике и набор методов из flash-секции, для возможности доступа к ним из Python по сигнатуре, объявленной в YAML.

class BattleResultsMeta(DAAPIModule): 
	def saveSorting(self, iconType, sortDirection, bonusType):
		self._printOverrideError('saveSorting')

	def showEventsWindow(self, questID):
		self._printOverrideError('showEventsWindow')


	def as_setDataS(self, data):
		if self._isDAAPIInited():
			return self.flashObject.as_setData(data)

BattleResultsMeta — базовый AS3 класс. В нем объявлен набор всех методов из python-секции YAML, для возможности доступа к ним из Flash по сигнатуре, объявленной в YAML. Именно эти методы объявляются как поля с типом Function, и они будут заменены на Python-методы из предыдущего пункта, после установки DAAPI-соединения.

public class BattleResultsMeta extends AbstractWindowView {
	public var saveSorting : Function = null;
	public var showEventsWindow : Function = null;

	public function saveSortingS(iconType : String, sortDirection : String, bonusType : int) : void {
		App.utils.asserter.assertNotNull(saveSorting);
		saveSorting(iconType, sortDirection, bonusType);
	}

	public function showEventsWindowS(questID : String) : void {
		App.utils.asserter.assertNotNull(showEventsWindow);
		showEventsWindow(questID);
	}
}

IBattleResultsMeta — AS3 интерфейс. В нем объявлен набор всех методов из python- и flash-секций YAML. Класс, реализующий функциональность окна послебоевой статистики, должен реализовывать этот интерфейс.

public interface IBattleResultsMeta extends IEventDispatcher {

	function saveSortingS(iconType : String, sortDirection : String, bonusType : int) : void;

	function showEventsWindowS(questID : String) : void;

	function as_setData(data : Object) : void;
}

Теперь для интеграции нового окна в клиент нужно выполнить несколько шагов.

  • Создать FLA-файл, в котором будет содержаться визуальная часть окна.
  • Во Flash создать класс BattleResults, наследуемый от BattleResultsMeta и реализующий интерфейс IBattleResultsMeta.
  • В Python создать класс BattleResults, наследуемый от BattleResultsMeta.
  • В Python создать константу, используемую как уникальный идентификатор нового компонента.
  • Добавить конфигурационные данные в Python, где будет указано соответствие между:
    — уникальным идентификатором нового компонента,
    — типом нового компонента (в нашем случае это окно),
    — файлом с визуальным представлением,
    — Python-классом, отвечающим за новый компонент.

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

Танцы с бубном закончены. Чтобы показать новое окно в клиенте, достаточно у Python-части нашего Application вызвать метод loadView, в который передается уникальный идентификатор нового компонента.

Что происходит, после того как мы вызвали загрузку нашего окна

Вот упрощенный алгоритм работы по загрузке и инициализации модуля (голубым цветом отмечены шаги в Python, розовым — во Flash):

image

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

  • управление загрузкой SWF-файлов;
  • управление распределением вьюшек по слоям и управление перехода фокуса между ними;
  • управление тултипами;
  • работа с локализационными строками;
  • управление звуковыми событиями;
  • управление контекстными меню;
  • управление анимацией;
  • управление и работа с цветовыми схемами;
  • другие задачи.

Планы на будущее

Самая объемная задача на обозримое будущее — перевод HUD на AS3. В текущий момент мы ведем исследования и готовим проект к такому переходу. Главное, чего мы хотим добиться в рамках этого перехода, — унифицировать механизмы добавления и разработки новой функциональности и избавиться от того разнообразия подходов, которое есть сейчас.

Мы также хотим как минимум не ухудшить производительность и потребление памяти новым HUD, а в лучшем случае — добиться прироста производительности и уменьшения объемов памяти, требуемых для работы HUD.

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

Самое узкое место — взаимодействие с отделом User Experience (UX). Сейчас при проработке новых игровых концепций или новой функциональности часто необходимо создать прототип, на базе которого можно (до передачи задачи в разработку) оценить удобство или простоту понимания основных механик простыми игроками.

Создание таких прототипов вне клиента дорого и не всегда может дать желаемый эффект. Не имея контекста или окружения, которые мы имеем в клиенте, мы не можем добиться нужного уровня погружения в игру. Остается создание прототипов внутри игрового клиента. Это тоже очень дорого, поскольку для этого приходится отвлекать разработчиков от их основного занятия и перенаправлять их усилия на выполнение работы, которая, возможно, будет полностью забыта и не востребована после проведения теста.

Даже если тест прошел успешно, то есть вероятность, что все придется переделать заново. В погоне за уменьшением затрат и из-за сжатых сроков на выполнение прототипа нам приходится зачастую прибегать к использованию «костылей», крупнозерновых «напильников» и заплаток.

Для решения этой проблемы мы планируем:

• создать набор стандартных компонентов (кнопки, индикаторы, списки и т. п.);

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

• создать инструменты быстрого прототипирования.

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

Вот и все, что я хотел и мог рассказать вам о GUI в World of Tanks. Задавайте вопросы в комментариях. Спасибо за внимание.
Автор: @Dichkovsky

Комментарии (27)

  • +6
    Когда вы наконец дадите в коммьюнити средства разработки клиентской части (гуй, ворлдэдитор, пр.)? Без этого довольно сложно пилить моды, и слишком увеличивает трудозатраты. А годных модов много, при чем есть большое количество хороших идей, которые увы не реализуются из-за отсутствия нужных утилит.
    • +3
      А конкурент в лице «Улиток» дал такой инструмент!
      • +5
        По протоптанной тропинке идти проще, да и подсмотреть на ошибки конкурентов и их «тонкие» места никто не мешает.
  • +1
    Вас принципиально устраивает Scaleform или уже созрело понимание, что есть что-то получше? Из текста я понял, что с одной стороны Вы не хотите останавливать бодрое рубилово, а с другой уже понимаете, что клиент имеет некоторые проблемы и ему нужна модернизация. Будете пытаться до последнего соблюдать баланс?
    • +1
      Вас принципиально устраивает Scaleform или уже созрело понимание, что есть что-то получше?

      А что есть лучше? На сегодня Scaleform — это «законодатель мод», если можно так сказать. Тут скорее вопросы к архитектуре самого WoT, что приходится идти на такие сложные шаги по внедрению.
  • +1
    Насколько я понял, вы используете SVN для контроля версиями. И ветками не пользуетесь (объясняет, как вам трудно делать прототипы и тестировать новые фишки).
    Переход на Git не думали? Ветки — наше все.
    • 0
      Да, используется SVN и конечно ветками мы пользуемся (не совсем понятно, почему Вы сделали такой вывод). Делать прототипы и тестировать новые фишки (если они не входят в планы на следующую версию) не трудно, а трудозатратно. Кроме прототипирования есть еще и большой объем текущих задач, а человеческий и временной ресурс ограничены.
  • +1
    А почему не перейдёте с Флеша на HTML/CSS/JS?
    • 0
      Уже обсуждалось в комментариях к первой статье — на Flash во много раз удобнее и быстрее можно сделать многие вещи (например сложные анимации) да и работать с ним IMHO удобнее, чем с JS. Так-же на момент выбора технологии Scaleform посчитали наиболее подходящим инструментом.
      • –1
        Согласен, Флеш разработчикам намного быстрее и удобнее сделать многие вещи на флеше. Мне тоже на JS проще и удобнее написать и консольную апку и десктопную и красивую анимацию. На момент выбора технологии может и было лучше, но это ж не значит что нельзя менять инструменты.

        Про сложные анимации — где они в WoTе? Сделать то можно быстрее, только вот будет ли работать эта анимация быстро, не отжирая все ресурсы, что гораздо важнее, т.к. пользуются вашим продуктом миллионы. Да и мне кажется вы недооцениваете возможности анимации в HTML, посмотрите хотя бы на bounce.js (анимацию при первом заходе на страницу).

        Тут скорее проблема в другом, есть люди и они умеют Флеш хорошо и не умеют хорошо HTML/JS, их надо либо переучивать, либо увольнять, либо искать им другой проект…
        • 0
          Если вы можете писать на JS, то и AS вам не будет в тягость, т.к. это один и тот-же язык.
        • +4
          не отжирая все ресурсы

          У Scaleform свой рендерер флеша и ресурсы он жрет куда скромнее, если сравнивать его с обычным флеш плеером. Грубо говоря «не жрет», а потребляет. Рендеринг графики происходит на видеокарте включая вектор с помощью революционной (по меркам Autodesk) технологии.

          Тут скорее проблема в другом, есть люди и они умеют Флеш хорошо и не умеют хорошо HTML/JS, их надо либо переучивать, либо увольнять, либо искать им другой проект…

          Найти хорошо умеющего и более дешевого HTML/JS разработчика гораздо проще, чем грамотного Flash'ера. Есть много «за» и «против». И по какой-то причине WatchDogs обошлись без HTML/JS, а вообще запилили UI на Flash безо всяких Scaleform.

          Rockstar (которые GTA делают) тоже с радостью на работу зовут Flash/Air/As3 программиста для работы над UI и прочими проектами. От Blizzard тоже не редко получаю приглашения на работу всё с тем же Scaleform. Сюда плюсую и Ubisoft с Electronic Arts.

          Но не зовут туда HTML/JS для тех же целей. Если бы у HTML/JS были бы хотя бы какие-то преимущества перед флешом в рамках данной темы — UDK не встраивали бы Scaleform в базовую комплектацию движка, а просто запилили бы бесплатную поддержку html/js.

          Тут не надо искать скрытых смыслов «почему Flash, а не HTML» и обижаться не следует. Достаточно спокойно принять, что каким бы html/js удобным не являлся — в ААА играх ему просто не место.
          • 0
            HTML/JS уже достаточно повзрослел, чтобы быстро работать в качестве GUI в игре. То что большие проекты еще не используют HTML/JS лишь дело времени, т.к. ААА проекты разрабатывают не один год.

            Найти хорошо умеющего и более дешевого HTML/JS разработчика гораздо проще, чем грамотного Flash'ера. Есть много «за» и «против». И по какой-то причине WatchDogs обошлись без HTML/JS, а вообще запилили UI на Flash безо всяких Scaleform.
            Тот же Watch Dogs начинали делать в 2009ом когда HTML/JS еще не был достаточно быстрым и функциональным для разработки GUI в игре.

            Rockstar (которые GTA делают) тоже с радостью на работу зовут Flash/Air/As3 программиста для работы над UI и прочими проектами. От Blizzard тоже не редко получаю приглашения на работу всё с тем же Scaleform.
            Рад за вас, но если вы Scaleform специалист, это не значит, что это лучшее решение на рынке, верно? Особенно если смотреть в перспективу. Flash более менее держится только в игросфере и как долго продержится — не известно, но пару лет можете дышать спокойно. Унификация выгодна как для больших компаний, держать специалиста который может и GUI и веб-портал удобнее.

            Но не зовут туда HTML/JS для тех же целей. Если бы у HTML/JS были бы хотя бы какие-то преимущества перед флешем в рамках данной темы — UDK не встраивали бы Scaleform в базовую комплектацию движка, а просто запилили бы бесплатную поддержку html/js.
            Это выгодно Эпикам по нескольким причинам, я думаю Autodesk нехило заплатила Эпикам за то, что scaleform там из коробки, во-вторых это сильно облегчит переход с UE3 на 4 тем кто уже использует Scaleform. У HTML/JS преимущество в виде огромнейшего комьюнити и количества хороших специалистов.

            Тут не надо искать скрытых смыслов «почему Flash, а не HTML» и обижаться не следует. Достаточно спокойно принять, что каким бы html/js удобным не являлся — в ААА играх ему просто не место.

            А кто обижается? Я недоволен тормозами GUI, особенно в аддонах, конкретной игры, и причины тут не только и не сколько во флеше, сколько в зоопарке технологий используемых для его отображения. Ведь игра написана на одном языке, гуи на другом, а между ними прослойка на питоне.

            в ААА играх ему просто не место
            Сами решили или это ревность? Боитесь что скоро Флеш вытеснят даже из игр?

            P.S. посмотрите, например, на Сoherent UI
  • +1
    HTML/JS уже достаточно повзрослел

    Вы меня извините, но я эту фразу слышу с 98 года. Сегодня начинают разработки игр, которые выйдут через год и всё равно единицы используют html/js. Просто примите тот факт, что html/js кодер это разработчик сайтов в первую очередь. Сами об этом говорили же. А в последнюю — это тормозящие приложения для мобильного телефона. Мы отказались от html5 в пользу других технологий, которые работают более адекватно.

    Тот же Watch Dogs начинали делать в 2009ом когда HTML/JS еще не был достаточно быстрым и функциональным для разработки GUI в игре.

    Я говорю о том Watch Dogs, который вышел в 2014 году. Дико сомневаюсь, что они используют одни и те же исходники с далеких 2009х.

    Рад за вас, но если вы Scaleform специалист, это не значит, что это лучшее решение на рынке, верно?

    Еще раз меня извините, но это утверждение адресую обратно Вам :) Вы отстаиваете html/js для GUI тогда, когда все сидят на Scaleform и не собираются с него уходить. И Вы говорите, что мы все должны согласиться с тем, что Scaleform не лучшее решение. Давайте я соглашусь с тем, что Scaleform не лучшее решение. Но оно во много раз лучше, чем html/js

    Особенно если смотреть в перспективу.

    Напомню еще раз. Scaleform — это полностью продукт Autodesk. Ничего общего с Adobe он не имеет и перспективы у него как у middleware — просто потрясающие. Если нужны исходники — можно их получить официально. И те, кто на это идет — наверняка у себя в офисе имеют верстальщиков сайтов, которые знают html/js. Но что-то им не дают заниматься подобным.

    А что касается Flash — я уже устал слушать разговоры о его похоронах. А он все живой и живой. Каждый год я слышу, что «вот в этом году он умрет точно!». Уже так с 2010 примерно. Прошу Вас — не разводите холивары о том, чо флеш плохой в теме, где пишут о том, как WoT использует флеш. Ну не нравится — не играйте, на худой конец. Просто напишите уже прямо, что Вы не обладаете опытом работы с флешом. Не надо писать почему — мы все поняли Вашу точку зрения. Он медленный, плохой, мертвый и логотип у него красного цвета.

    Унификация выгодна как для больших компаний, держать специалиста который может и GUI и веб-портал удобнее.

    Я себе слабо представляю, чтоб компания, которая делает ААА продукт — нагружала UI разработчика еще и дизайном портала и версткой. Это наверное наш отечественный «совковый» подход, когда один человек и на балалайке играет и лампочки с унитазами меняет :)

    я думаю Autodesk нехило заплатила Эпикам за то, что scaleform там из коробки

    Обычно платят в обратную сторону. Но в любом случае истины мы не узнаем.

    У HTML/JS преимущество в виде огромнейшего комьюнити и количества хороших специалистов.

    Я за это уже писал. Найти дешевого и хорошего html/js верстальщика/программиста не составит труда. Но почему-то так не делают и наверное им лучше знать причины таких решений.

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

    У этой проблемы есть альтернативные пути решения и они никак не связаны с html/js. Ввиду использования as2 — они все осложнены. Из данной статьи я вижу сразу массу проблем с архитектурой. Но это все решаемо при наличии желания и технико-экономического обоснования у компании.

    Что касается тормозов в других играх — Вы наверное не до конца понимаете как работает Scaleform. У Вас на экран выводится не флеш, а набор полигонов с вершинным и фрагментным шейдером. Если это у Вас тормозит — тогда тормоза в коде приложения, а не Scaleform.

    Вот игра полностью сделана с помощью Scaleform и она не тормозит. Почему — объяснить лениво. Вы в любом случае найдете к чему придраться, т.к. это не html/js, а Flash.


    Сами решили или это ревность? Боитесь что скоро Флеш вытеснят даже из игр?

    Ну что Вы :) Я лишь констатирую факт — ААА продукты используют Flash. А Вы в который раз намекаете, что большие компании не используют html/js в интерфейсах.

    P.S. посмотрите, например, на Сoherent UI

    Замечательно! Есть дешевые альтернативы для не тайтловых игр под стим. Но запомните одну вещь. Черепаха танком не станет, сколько бы брони на себя не одела.
    • 0
      Вы отстаиваете html/js для GUI тогда, когда все сидят на Scaleform и не собираются с него уходить.
      Конечно, а еще все испольщуют Маки и у всех по ведру айПхонов 5Эс в каждом кармане. Я отстаиваю html/js как еще одну альтернативу, которую используют некоторые проекты. Я так понимаю, вам все разработчики сообщают о своих планах или только те, что вы перечислили в предыдущем комментарии?

      Что касается тормозов в других играх — Вы наверное не до конца понимаете как работает Scaleform. У Вас на экран выводится не флеш, а набор полигонов с вершинным и фрагментным шейдером. Если это у Вас тормозит — тогда тормоза в коде приложения, а не Scaleform.
      Где я писал про тормоза в других играх? Если HTML/JS тормозит, проблема тоже в коде.

      Но оно во много раз лучше, чем html/js
      Очень аргументированный ответ.

      Я себе слабо представляю, чтоб компания, которая делает ААА продукт — нагружала UI разработчика еще и дизайном портала и версткой. Это наверное наш отечественный «совковый» подход, когда один человек и на балалайке играет и лампочки с унитазами меняет :)
      Снимайте броню, осмотритесь по сторонам. Я же не говорил, что человек будет делать все сразу, просто загрузка в разное время разная, а возможность утилизировать человека будет. Во-вторых у вы читаете, что html/js это только дизайн и верстка. Наверное я для вас открою секрет, что уже немало приложений используют ноду в качестве бекенда, да и html/js приложений тоже не мало. Ой да, кстати очень много игр используют их в Ланчерах. А еще есть WebOS, которая очень шустро работает на новом поколении телеков LG, причем представляете в качестве GUI. Есть FirefoxOS, ChromeOS.

      Найти дешевого и хорошего html/js верстальщика/программиста не составит труда.
      Вы вообще пробовали искать их? Я знаю много хороших парней и они отнюдь не дешевые, а еще через меня прошло много «хороших» и недешевых фронтендщиков, которые писали что они там сеньоры и все дела, а на деле обычные jun2middle. Есть хорошие и дорогие, их не так много как вам кажется, их еще меньше чем хотелось бы, но их больше чем специалистов по Scaleform.

      А что касается Flash — я уже устал слушать разговоры о его похоронах. А он все живой и живой. Каждый год я слышу, что «вот в этом году он умрет точно!». Уже так с 2010 примерно. Прошу Вас — не разводите холивары о том, чо флеш плохой в теме, где пишут о том, как WoT использует флеш. Ну не нравится — не играйте, на худой конец. Просто напишите уже прямо, что Вы не обладаете опытом работы с флешом. Не надо писать почему — мы все поняли Вашу точку зрения. Он медленный, плохой, мертвый и логотип у него красного цвета.
      Я и не говорил что он умер, я сказал что умирает. Я не говорил, что он плохой. Вы очень предубежденно относитесь. Флеш почти ушел из веба, для которого изначально создавался, он остался в геймдеве. Кстати, знаете почему флеш умер в вебе? Потому что в своё время Ёпл не сделало поддержу его в йФоне, потому что тормоз, жрет ресурсы и т.д. Может слышали, такой мелкий игрок на рынке…
    • 0
      В добавочек:
      Вы наверное не до конца понимаете как работает Scaleform. У Вас на экран выводится не флеш, а набор полигонов с вершинным и фрагментным шейдером.
      То же касается и вас, вы не до конца понимаете, что современные движки тоже не рендерят все оппиксельно, а давно выводят набор полигонов с шейдерами.
  • +1
    Конечно, а еще все испольщуют Маки и у всех по ведру айПхонов 5Эс в каждом кармане. Я отстаиваю html/js как еще одну альтернативу, которую используют некоторые проекты. Я так понимаю, вам все разработчики сообщают о своих планах или только те, что вы перечислили в предыдущем комментарии?

    Вы меня немного не знаете просто ;) И мне сообщают не о планах, а задают вполне конкретные вопросы с оплатой за ответы на них. Это так, хобби — помогать людям.

    Конечно, а еще все испольщуют Маки и у всех по ведру айПхонов 5Эс в каждом кармане.

    Не понял для чего это было сказано? Ну у меня собачка есть Чихуахуа и монитор Dell 2560х1440. Что это меняет? :)

    Если HTML/JS тормозит, проблема тоже в коде.

    Естественно в коде. Только скорее всего не в js коде, а с++, который выполняет этот js.

    Очень аргументированный ответ.

    А какие аргументы нужны? Мне не 15 лет, чтоб доказывать, что птица это не самолет. Я думаю в игрострое это и так многие знают.
    Разве не аргумент, что известные и мощные компании используют Scaleform?

    Disney Infinity 2.0 Edition — Marvel Super Heroes от Electronics Art осенью 2014 года релизят игру с использованием Scaleform. Туда же от них же Sims 4 на сентябрь.
    Sunset Overdrive от Microsoft тоже будет использовать Scaleform. И релиз назначен на конец октября 2014 года. Это вообще для начала… Лень список продолжать.

    Почему они все такие глупые и не используют HTML/JS? Надо написать им в твиттер, что они слепы как дети, т.к. лучше html/js ничего нет! Представляю я себе верстальщика, который утром код вставки яндекс карты делает, а вечером пилит интерфейс на html в игре, где минимальные сборы под 10ку лямов зелени.

    что уже немало приложений используют ноду в качестве бекенда

    приложения != игры, ну сколько можно уже об этом всем говорить

    Ой да, кстати очень много игр используют их в Ланчерах.

    Ну так Ланчер это не игра ;) Можно и на vb6 писать его. Кстати, для справки.Сейчас всё больше игр для Ланчеров использоуют Adobe Air.

    А еще есть WebOS, которая очень шустро работает на новом поколении телеков LG, причем представляете в качестве GUI. Есть FirefoxOS, ChromeOS.

    Я не против, что html/js будет работать хоть на туалетном зеркале. Но это все не является игрой. И с JS я знаком не по наслышке. Если бы он был бы такой классный, то таких вещей как typescript вообще не появилось бы. Никто не любит велосипеды писать, когда делают серьезные продукты. Если компания хочет использовать SWF формат — уверяю, что там есть много людей, кто им сайты делает и мобильные приложения. Они в курсе, не надо их учить зарабатывать их деньги :) Я бы у них лучше поучился.

    Вы вообще пробовали искать их?

    Пробовали. Пока все получается. Но я ищу обычно на фриланс основе или на временный трудовой договор «под проект».

    но их больше чем специалистов по Scaleform

    Специалистом по Scaleform может стать любой as3 программист с as2 опытом, который знает что делает. Таких много. Очень много. Может быть не столько, сколько по html/js, но их вполне достаточно.

    потому что тормоз, жрет ресурсы и т.д

    Я еще слышал, что флеш разряжает аккумулятор, а html5 его заряжет. Флеш заражает вирусами компьютер, а javascript лечит.

    P.S. находясь в Adobe Advisory Team (не путайте с Prerelease, это более мелкая группа, которая входит в Advisory) имею более «реальные» версии отсутствия флеша на девайсах.
  • 0
    Вы меня немного не знаете просто ;)
    Вы же тоже меня не знаете. Если бываете в столице, это можно исправить.

    Не понял для чего это было сказано? Ну у меня собачка есть Чихуахуа и монитор Dell 2560х1440. Что это меняет? :)
    к тому что я и выделил, вы писали "все сидят на Scaleform и не собираются с него уходить."! P.S. У меня тоже Dell 2560x1440 :D

    Естественно в коде. Только скорее всего не в js коде, а с++, который выполняет этот js.
    Вы вероятно давно ничего не писали на JS, раз так утверждаете ;-)

    Пробовали. Пока все получается. Но я ищу обычно на фриланс основе или на временный трудовой договор «под проект».
    Значит вероятно мы говорим о разного рода людях, требования ведь очень разные.

    Я еще слышал, что флеш разряжает аккумулятор, а html5 его заряжет. Флеш заражает вирусами компьютер, а javascript лечит.
    Неправда, JS не дает простудиться зимой, как и флеш. Но это благодаря криворуким программистам.

    Disney Infinity 2.0 Edition — Marvel Super Heroes от Electronics Art осенью 2014 года релизят игру с использованием Scaleform. Туда же от них же Sims 4 на сентябрь.
    Sunset Overdrive от Microsoft тоже будет использовать Scaleform. И релиз назначен на конец октября 2014 года. Это вообще для начала… Лень список продолжать.

    Почему они все такие глупые и не используют HTML/JS? Надо написать им в твиттер, что они слепы как дети, т.к. лучше html/js ничего нет! Представляю я себе верстальщика, который утром код вставки яндекс карты делает, а вечером пилит интерфейс на html в игре, где минимальные сборы под 10ку лямов зелени.
    «миллионы не могу ошибаться»! Ну вероятно такие же упрямые консервативные как и вы. Другого объяснения не вижу :D
    Так собстенно по делу, чем конкретно лучше Scaleform перед HTML/CSS/JS? Раз вы профессионал и в то и в том, может проведете сравнительный обзор? Замеряете производительность, сравните набор фич… Назовете статью «Почему HTML/JS еще не дорос до AAA+ игр», только объективно сравнивайте. Сообщество Хабра не забудет вас!!!
  • 0
    Вы вероятно давно ничего не писали на JS, раз так утверждаете ;-)

    Ну почему же? Я даже могу согласиться, что JS будет быстрее в некоторых моментах.

    Если бываете в столице, это можно исправить.

    В Киеве буду не раньше, чем через год. В Москве бываю чаще :)

    к тому что я и выделил, вы писали

    Естественно имел ввиду только ААА тайтлы известные. Да и не известные тоже, но от не мене известных.

    «миллионы не могу ошибаться»! Ну вероятно такие же упрямые консервативные как и вы. Другого объяснения не вижу :D

    ))))))) На самом деле всё не так. Миллионы могут ошибаться и мы это часто видим с телевизора. Просто есть люди, которые вырабатывают workflow и работать по гайду куда дешевле, чем менять весь концепт подхода к процессу.

    Замеряете производительность, сравните набор фич…

    Я зарекся больше тестов не делать. Просто поверьте на слово. Если не мне, так хотя бы — титанам индустрии (Ubisoft, Microsoft, EA, K2, Activision и т.д.). Они уж точно лучше меня и Вас (простите, если обижаю) в этом разберутся :)

    Сообщество Хабра не забудет вас!!!

    Если честно я тут появился ради камментов в одной статье ;)

    P.S. Я не отрицаю, что html/js в GUI имеет место быть. Я лишь утверждаю, что это не является панацеей для устранения всех косяков в Scaleform. А известные компании не бегут внедрять html/js в свои GUI по ряду причин, часть из которых была озвучена в статье. Проще говоря — самолеты и автомобили не просто развиваются параллельно, но еще и выполняют разные функции. Хотя, не редко, у них одинаковые задачи. Так и scaleform vs html/js

    На этом я более не нацелен вести диалог — надо готовиться к презентации. Спасибо за беседу!
  • 0
    Сильно ли различается работа интерфейса в танках и самолётах?
    На глазок в WoWp всё как-то шустрее, особенно в ангаре на максимальных настройках графики заметно, в танках у меня будет просто фееричный полёт курсора в густом густом киселе, тогда как в самолётах при том же раскладе курсор двигается без каких-либо «затруднений». Why?
    • 0
      Архитектура GUI отличается сильно. По сути это два разных проекта. С курсором такая картина, т.к. в WoT он программный и рисуется во Flash, а в WoWp курсор — аппаратный.
      • 0
        Происходит ли обмен наработками между разработчиками WoT, WoWP и WoWS?
        С тем же курсором в желе будете что-нибудь менять из опыта коллег?
        • 0
          Обмен, безусловно, происходит. Про то, что будет с курсором в WoT — не скажу (задачи такой не видел), но то, что проблему озвучили хорошо. Рекомендую обратиться с этим вопросом в поддержку, оформить инцидент с подробным описанием системы и выбранных настроек — так быстрее и правильнее будет.
  • 0
    С курсором такая картина, т.к. в WoT он программный и рисуется во Flash

    А что за курсор программный? Флеш больше 4х лет поддерживает аппаратную смену курсора из картинки. Ограничение накладывается лишь самой операционкой по его размеру.
    • 0
      А что за курсор программный?

      На сцене создается MovieClip, который передвигается при движении мыши в нужные координаты. Системный курсор убирается совсем.
      Флеш больше 4х лет поддерживает аппаратную смену курсора из картинки. Ограничение накладывается лишь самой операционкой по его размеру.

      Ну мы же про Scaleform говорим, а не про Flash Player
  • 0
    Ну мы же про Scaleform говорим, а не про Flash Player

    Да, пардон :) Веткой ошибся.
  • 0
    Возможно я поздно со своим вопросом, но сколько я не копался в недрах Bigworld и в танках вообще, не могу понять DAAPI реализации взаимодействия fp и python. Вы его сами написали? Насколько я понял, Bigworld меняют свою архитектуру и учитывают ваш опыт в написании своего продукта — вы не поделились своим DAAPI? Вы впервой статье описывали проблему сборки swf, где базовые или экспортные swf-ки старой версии могли перекрыть новые реализации и по этому игра падала — как вы решили это? Очень хочется(как разработчику игр) почитать больше про ваш опыт работы с bigworld и scaleform в деталях, не переступая "Соглашение о Неразглашении".

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка