Category: игры

Category was added automatically. Read all entries about "игры".

flow

Новый контроллер от Valve

http://store.steampowered.com/livingroom/SteamController/

Мне нравится идея с трекпадами-динамиками. Если её сначала отладить на такой чувствительной области как игры до хорошей точности, а потом перенести на клавиатуры и офисы/САПРы (например: правый пад - курсор мыши, левый пад - скролл документа), то можно оставить мышь только для игр (лол).

Когда и допилят ли - вот вопрос. Мы же помним, что было с их предыдущей командой железячников.
flow

Королевство кривых зеркал

Смотрел на неделе трансляции с нашей любимой E3. Обратил внимание, что тенденция наделения игр кривыми (в буквальном смысле) интерфейсами, которая наблюдается последние несколько лет, достигла своего апофеоза.

У всех элементов GUI и HUD есть своё пространство. Это может быть плоскость экрана или какая-либо поверхность в игровом мире. Изначально всё было в плоскости экрана, даже какие-то подсказки/HP над объектами трёхмерных игровых миров и показания датчиков в случае "вида из кабины". Но время шло, технические возможности менялись, на месте рычагов в играх появлялись терминалы управления шлюзами, индикатор с количеством патронов появлялся прямо на модели оружия, etc. Когда вышел Doom 3, дизайнеры сказали "хотим как у них", а у меня появилась задача - написать к новой игре новый GUI-движок (и, соответственно, GUI-редактор), не теряя совместимости с говнокодом данными завершавшихся проектов. Далее - артист рисует, скриптовики пишут логику, получается множество экранчиков GUI3D в проекте Exodus From The Earth, которые приятно оживили игровой мир.

Однако, в том же Doom 3, помимо GUI3D в игровом мире и HUD в плоскости экрана, проявляются искажения - разный наклон шрифтов в разных частях HUD. Как безобидная стилизация, ибо шрифты всё ещё читаемы. Но тенденция развивается, да ещё и усугубляется с распространением дебильного Scaleform, GUI-движка, пайплайн в котором заточен на быструю штамповку 100500 ручных лэйаутов и анимаций со skew/rotate. И все начинают штамповать...

И получаются кривые меню, перекошеные плашки HUD и прочая хрень, которая по своей специфике отображения не может быть отнесена ни к плоскости экрана, ни к какой-либо из поверхностей или плоскостей игрового мира. Это и псевдонаклонные меню/записки в Dishonored и кривой HUD в обеих Borderlands, который не имеет ничего общего с эффектом "проекции на стекло шлема". Наблюдать подобные эшеровские картины в игре и поверх игры - сильная когнитивная нагрузка.

Пример из анонсов E3 - The Division: https://www.youtube.com/watch?v=uiaRSuyQ7zA Много, дорого, красиво, но чудовищный HUD превращает всё в тыкву.

Геймдев - единственная ниша, где допустимо немного жертвовать удобством интерфейса ради усиления развлекательности. Единственная ниша, где допустимо начинать разработку интерфейса с артиста. Но это не повод снижать требования к качеству.
flow

Про GUI, игры и реальное время

В коде игр есть такая прекрасная штука - игровой цикл (game loop).

Для типичной игры он выглядит так:

1. Узнать системное время и новый input со стороны клавиатуры, мыши, геймпадов, etc.
2. Выполнить шаг симуляции игрового мира - логики, физики, AI, GUI/HUD и других подсистем.
3. Обновить картинку и звук.
4. Перейти к шагу 1.

Элементы 1-3, а также их фрагменты, часто обозначают словом таймтик (timetick): таймтик физики, таймтик рендерера. Симуляция может учитывать не только события между двумя срезами времени, но и глобальные затраты ресурсов. Например, когда бот в трёхмерном шутере выбирает новую позицию для стрельбы, то на "посмотреть-посмотреть-подумать" могут потребоваться заметные вычисления. Чтобы не происходило фриза (freeze) от одновременно задумавшихся ботов и частота обновления картинки оставалась в пределах нормы - ботов учат действовать одновременно, но думать по очереди.

Код игрового движка часто обновляется или заменяется между играми. Программисты пишут game loop первый, второй, десятый раз. Опытные геймдевелоперы способны спроектировать game loop левой ногой, на непонятом ими языке программирования, и результат будет хорошо работать (пример - исходники Doom 3).

Так делаются игры. И так должны делаться приложения. Ввод-обработка-вывод-повторить это основа любого программного обеспечения, под разными именами - game loop, REPL. Фоновые задачи в отдельных тредах и обработчики запросов на сервере - то же самое, с вводом/выводом в промежуточной "машинной" форме.

Однако, loop во многих системах GUI выглядит иначе. Вам предлагают множество мелких объектов, которые связаны через обработку сообщений, которые придут сюда, если их не поймают в чужом коде вот здесь, но для accelerator'ов они пойдут иначе, в в случае модального диалога всё совсем не так. Взаимодействие по принципу "вчера положили асфальт, но сегодня вскрывают для плановой замены труб". У вас есть множество привязок обработчиков и датабайндингов, "что и где", но никто не может ответить на вопрос "когда?". Ошибки, артефакты, фликающие или недорисованные окна, тормоза и странности - а чего вы ещё хотели, если игнорируется время?

Полноценные системы GUI проектируются редко. Обычными людьми, как мы с вами, которые делают это в первый или второй раз. Некоторые проектировались под требования тех ещё времён ("сэкономить 10 килобайт на окно любой ценой"), некоторые проектируются по образу и подобию привычных авторам древних решений. Даже при использовании кроссплатформенных API темпоральные аспекты выполнения кода приложения могут отличаться самым чудесатым образом.

Что делать? Как получить хороший отзывчивый UI приложения в таком бардаке? Решение есть.

Заменить дефолтные механизмы на свой game loop. Даже выделение из бардака сообщений двух таймтиков на "сначала закапывать трубы" и "потом класть асфальт" принесёт пользу, исправит ошибки и ускорит отрисовку интерфейса. Можно на этом остановиться. А можно продолжить, и решить остальные проблемы.

Главное - помните, если в треде вы взаимодействуете с временем пользователя, то для любого клочка кода должны знать его "когда", иначе будете постоянно огребать "невовремя".
flow

2012

Итоги.

Большую часть года я занимался проектом .15926 (dot15926) как архитектор, а затем консультант. Основной продукт из просмотрщика/редактора эволюционировал в единственный мини-САПР для ISO 15926. Это круто, но надо думать о будущем. Нарисовался круг вопросов, на многие нашлись ответы. На первый план вышла тема бинарного протокола/контейнера, и уже можно писать реализацию (буквально неделю назад было ещё нельзя :) Пост с описанием соответствующих проблем и решений в системе типов тоже надо бы сделать.

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

Месяц провёл с ногой в гипсе, без тренировок тяжко, так что задействовал обычно игнорируемые компьютерные игры и был приятно удивлён разделом Indie на Steam. Да я за последние пять лет в сумме столько не наиграл, сколько тогда. И время на игры не казалось потеряным. Возможно дело в качестве доступных сейчас (благодаря Steam и Kickstarter) игр. Возможно дело в гипсе.

Путешествовал. Япония очаровала абсолютно, мы снова туда вернёмся, а потом ещё раз захотим вернуться. Испанию интересно узнать ближе. А вот Германия никак, я понял про "там хорошо работать, но скучно жить".

А надо, чтобы всё нескучно. Вообще, так и получается. Но когда так получается, то совсем не получается стабильных долгосрочных планов. Впрочем, когда вы в наше время видели, чтобы долгосрочные планы работали? ;)