Начнём с вводных. Мы разрабатываем программу, которая будет сохранять свои данные в файл, и при этом…

• будет расширяться, и существенно (отпадают уровни и сохранения большинства игр: после пары патчей бросаем игру и пишем новую);
• тем не менее программа не рассчитывает на то, чтобы быть стандартом (отпадает LibreOffice). То есть по формату сохранения она должна быть совместима только с собой-старой и собой-новой;
• все её данные надо держать одномоментно в памяти; СУБД типа SQLite не даёт каких-то преимуществ (отпадают базы переписки в почте или мессенджере);
• но файл сохранения будет очень велик (отпадают программы фотопроявки вроде Lightroom, где документ — это всего лишь положения сотни-другой ползунков: мелочь по сравнению с 40-мегабайтным RAW);
• нет нужды в ручной корректировке файлов (отпадает пользовательский интерфейс типа «файл конфигурации», присущий, например, серверу Apache).

Таких программ на самом деле немало. Это AutoCAD, Photoshop, Microsoft Office (будем честными: даже пытаясь протащить его через ISO, «мелкомягкие» рассчитывали, что он будет совместим в первую очередь с самим собой).

И для простоты добавим ещё одно требование, которое отбросит все три этих программы, но довольно реалистичное (ему отвечают Windows 10 и куча программ помельче).

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

Первая часть

От переводчика. OlegKozlov рассказал о приёмах камеры в своей игре «Несыть». Из-за большого количества трафика и не слишком верно действующего JS якорь перебрасывает куда угодно, только не на комментарий, поэтому сделаю копию здесь.

Ну и по поводу навязчивости и комфорта. Было тяжело переводить и ещё тяжелее вычитывать, анимация в периферийном зрении очень мешала, да и нагруженные анимацией страницы заглючивали «рыжую». И простите, что на день бросил первую часть под замок.

Направление

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

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

Wonder Boy, ещё одна моя любимица, быстрый платформер, в котором можно идти только вперёд через старое доброе одностороннее окно свободного хода. В отличие то Super Mario Bros., там нет зоны разгона, плавно ускоряющей камеру, но есть другая интересная техника, которую я называю «рельсы». Камера ставится и движется так, чтобы предвосхищать будущие преграды.

Wonder Boy (Sega, 1986)

Рельсы: запрограммированный маршрут камеры Зона свободного хода (односторонняя) Статическое упреждение

Пятое поколение приставок, среди них PlayStation и Nintendo 64, открыло новые аппаратные возможности, положив начала грубому, но настоящему 3D. Приёмы трёхмерной камеры — сами по себе захватывающая и многогранная тема, но поддержка 3D повлияла и на двухмерные игры. Разработчики теперь могут приближать камеру, наклонять вид и даже сочетать 2D и 3D — то, что мы сейчас называем 2,5D, когда игра идёт на двухмерной плоскости, но в объёмном мире.

Вторая часть

От переводчика. Статью написал Итай Керен, основатель инди-студии Untame, автор игры Mushroom 11. Получился настоящий учебник по управлению камерой в играх с боковой прокруткой. Хоть там нет ни строчки кода ни на каком языке (вру, одна есть), думаю, несложно будет перевести всё это в инструкции для компьютера. Обязательно к прочтению всем программистам и дизайнерам, которые занимаются динамичными 2D-играми. Терминологию я переводил больше по смыслу: например, position-locking — «привязанная камера». Да, и для многих игр до 1983 года показана версия для Dendy — немного неисторично, но простим.

Введение

Работая над игрой Mushroom 11, я натолкнулся на множество дизайнерских и технических вопросов. Я не рассчитывал, что кто-то напишет о вершинной анимации или плавном изменении формы, но я удивился, что по работе с камерой, задаче с 30-летней историей, тоже практически не пишут.

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

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

Игроки часто пользуются субтитрами речи и важных звуков; чаще, чем потребители других видов медиа. Этому много причин — не только потеря слуха, но и плохие мобильные динамики, окружающий шум, спящий ребёнок. А ещё — риск, что важная реплика потеряется в игровом шуме. Наконец, в играх часто локализуют одни субтитры.



Так что неудивительно, что в опросе CNet по субтитрам 79% игроков сказали, что играют с субтитрами. Цифра довольно ненаучная, но уже она говорит, что с субтитрами играют очень часто.

И, несмотря на всё это, субтитрам часто не уделяют надлежащее внимание. Субтитры часто приделывают перед самым выходом, а не прорабатывают как неотъемлемую часть интерфейса. Хорошую систему титрования лучше сделать наперёд, чтобы потом заполнить текстом, когда тот появится.

Во многих типах игр, не только стратегических, у вас есть участок земли, и на нём нужно что-то строить. Знакомая схема, не правда ли?



Как только вы перетаскиваете постройку из «магазина» на участок, она некоторое время строится. Обычно в это время там видна одна картинка, похожая на стройплощадку. Чтобы сэкономить память и бюджет, во многих играх нарисовано три таких «стройплощадки», под разные здания: маленькая, средняя и большая. Как только строительство закончено, стройплощадка превращается в готовое здание.

Но что, если вы хотите более тонкие анимации, чтобы было видно, как здание постепенно растёт к небу?

Статье 14 лет. Но, что удивительно, перевода этой классики на Хабре нет. Значит, будет.

Итак, вы называете себя «проектировщиком интерфейсов»? Если не сможете на все вопросы ответить быстро и обоснованно — вон из профессии!

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

А если вы не знаете, что такое «закон Фиттса», просто пройдите тест, не подсматривая в ответы. Это прояснит, какими стереотипами вы руководствовались. В ответах — подробный разбор задействованных принципов, и вы можете сравнить свои стереотипы с моими ответами. И не пугайтесь плохих результатов: большинство людей, даже давно знакомых с компьютерами, в первый раз проходит тест очень плохо. Зато во второй раз ответы получаются правильные, и большинство считает эту статью самой ценной на моём сайте: одно её прочтение улучшит все интерфейсы, спроектированные в дальнейшем.

Эти вопросы предполагают, что всё экранное пространство под вашим полным контролем. Просто представьте себе, что вы главный дизайнер в Microsoft или Apple.

Редко доводится скромному программисту подловить СамиЗнаетеКого. Перед нами свежий «Бизнес-линч».



Посмотрим на две самые большие машинки, белую и голубую. Похоже, что белая — это 70 тысяч, а голубая — 40? По-моему, нет, на глаз втрое-вчетверо больше.

Представьте себе такую ситуацию:

• У нас есть внутренняя утилита (скажем, редактор уровней). Время от времени выходят новые версии.
• Информация хранится в XML или другом древовидном расширяемом формате. При этом мы, как светлые джедаи, следим за совместимостью «снизу вверх», и более поздние версии открывают все ранние проекты.
• Утилитой пользуются люди нетехнические и не подверженные «синдрому раннего подражателя». Им не обязательно иметь свежайшую версию редактора; главное — стабильную и одинаковую в рамках одного проекта.
• Время от времени появляются новые функции, в XML для этих функций появляются новые блоки. При этом возможна такая ситуация: пусть над одним проектом работают двое. У одного программа новые блоки поддерживает, у другого — нет. Второй, сохранив проект, просто потеряет эти блоки.

Приходит мне спам (орфография авторская):

Привет, a нафига ты всем спам присылаешь. Пожалуйста перестань. Вот зацени msguard.com как защитить свой компьютер от вируcов

Захожу на сайт, смотрю лицензионное соглашение, рассчитывая увидеть очередную «игровую программу» — и вижу:

Здравствуйте! Публикую пост от безысходности — никто из знакомых не подсказал, у самого Windows 32-битная, а Google даёт мусор. Итак…

Отладчик Builder 2010 подсказал мне: DLL, в котором устроен хук WinAPI, просто-напросто вставляется в адресное пространство каждой программы. В связи с этим возникают пара вопросов.

1. Будет ли работать 32-битный хук клавиатуры под 64-битной версией Windows?
2. Будет ли наоборот: 64-битный хук клавиатуры под 64-битной виндой, но в 32-битных программах? Если нет — как корректно сделать двойной хук?