Category: it

Category was added automatically. Read all entries about "it".

Заметки по конференции Frontend DevConf (Минск, 18 апреля 2015)

MapBox


-- Клёвая технология отрисовки географической информации (карт) из OpenStreetMaps. Есть для WebGL чтобы юзать в браузере, есть для C++, чтобы юзать в приложениях. Opensource. Для геосоциальных игр must have.

github/mapbox



Управление восприятием времени в UI


Восприятие пользователем времени при работе приложения очень  важно. Platform Success Model (Google): НИКАКИХ ЗАДЕРЖЕК!



  • 40% пользователей уходит с сайта если он грузится более 3 секунд


  • 1сек. ожидания = 7% потеря конверсии



Как пользователь оценивает скорость задержки при реакции сайта на свои действия (в сек.):


  • 01-02 = мгновенный


  • 0.5-1 = быстрый


  • 2-5 = медленный


  • 7-10 и больше = порог внимания. при такой задержки чел. не сможет удерживать UI в фокусе внимания. или уйдёт или переключиться на что-то другое.



Закон Weber-Fechner -- пользователь способен заметить разницу в длительности только если оно отличается на 20% и более.

Мало смысла оптимизировать скорость загрузки если это даст выигрыш менее 20%, так как юзер ничего не заметит.


Не можешь поменять что-то -- поменяй отношение к этому.

Если мы не можем заставить процесс выполняться быстрее, мы можем поменять отношение пользователя к ожиданию. Замаскировать его.


Перенос точки восприятия страницы с момента окончания загрузки на на момент самого начала.


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


  • Другой пример -- при загрузке ленты в FB показываются муляжи постов вместо ещё не загрузившейся ленты. Пользователь не успевает заметить этого.


  • Реплика из зала: У нас замена собственного спиннера загрузки (анимированного колечка) на системный привела к тому, что пользователи думают, будто приложение работает нормально, а тормоза из-за того, что телефон медленный :).



Какой индикатор загрузки лучше использовать при задержках


  • 2-5 сек = без отображения прогресса, например спиннер;


  • 5-10 сек = с отображением прогресса сколько % уже сделано, например прогресс-бар;


  • >10 сек = писать estimate цифрой (пример -- инсталлятор Windows);



Когда мы пишем юзеру estimate, важно использовать следующие цифры (Time Anchors):


1, 2, 3, 5, 10, 15, 20, 25, 30

----------------------------------->

Это “естественные длительности”, комфортные пользователю. Например, ему будет Ok если мы пишем что процесс займёт 5 минут, даже если он занял 6. Пользователь не заметит разницу инртервала меньше 20%. Если же мы напишем 6, то это привлечёт его внимание, он будет замерять интервал.  Вместо 45 минут лучше указать 1 час. Пользователь будет доволен если заметит, что реальное время будет меньше ожидаемого, но не наоборот. И т.д.


Когда мы пишем про интервал, нежелательно перескакивать через соседние значение.

Нормально писать, что загрузка займёт 5-10 минут, но не 5-20 минут. Это дезориентирует пользователя, так как 5 минут и 20 для него слишком разные активности. 5 минут это “выпить чаю”, а 20 это “сходить в магазин”. Лучше тогда писать, что загрузка займёт до 20 минут.


Использовать с пользой время ожидания:


  • Показать пользователю, что это время стоит того, и он получит что-то ценное в конце



Управление временем:

Делать быстрее→ Менять отношение → Показать что стоит ждать



Ресурсы посмотреть:



  • Лекции Андрея Короткова на YouTube


  • книга “Сюрреализм на Java Script”


  • книга “Game Engines Architecture”


  • andyjr

Бесплатный семинар по геймдизайну

Оригинал взят у andyjr в Бесплатный семинар по геймдизайну
23 августа 2014 года в Москве пройдет очередной бесплатный семинар от Академии Разработчиков Игр.

Что будет обсуждаться на встрече:
• Команда проекта и ее состав
• Выработка концепции игры
• Основные причины неудач концептов
• Как дешево и быстро проверить концепт
• Какие виды и приемы прототипирования бывают
• Секретные техники Академии Разработчиков Игр

seminar1

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

Записаться на семинар можно по этой ссылке.

  • andyjr

Авангард Онлайн: как кидают в русском геймдеве (часть 4)

Оригинал взят у andyjr в Авангард Онлайн: как кидают в русском геймдеве (часть 4)

“Бойтесь своих желаний - они могут исполнится!” - гласит народная мудрость. За десять месяцев работы над своей игрой Авангард Онлайн я сполна убедился в справедливости этого изречения. Наивная мечта обернулась ежедневным просиживанием стула в неотапливаемой каморке. Несмотря на то, что игра зарабатывала около 200 000 рублей в месяц, вместо денег все мы получали сладкие обещания нашего руководителя Саржа.

AVAp4_1

Должен признать, что Сарж демонстрировал чудеса логики и изобретательности, придумывая аргументированные объяснения нашего плачевного положения.
Collapse )

Прототипирование диалогов

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

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

Конечно, если у нас есть на руках игровой движок, то можно создавать диалоги прямо в нём. Но не всегда на момент написания сценария движок уже существует. А если он и существует, то совсем не факт, что там легче писать и отлаживать диалоги чем  в простом текстовом редакторе (иногда даже наоборот).  Вот почему полезно иметь под рукой средства быстрого прототипирования. Не могу назвать себя гуру в этой области, но хотел бы рассказать про два очень разных инструмента:


1) движок INSTEAD. Вообще-то он предназначен для написания текстовых adventure-like игр на языке Lua, но поддерживает спрайтовую графику и звук. Кроме всего прочего, предлагает готовые средства создания диалогов, работы с инвентарём и переходов между локациями. За счёт очень большой гибкости он может использоваться гораздо шире той области для которой позиционируется, в том числе для прототипирования.




Достоинства:

  • Бесплатный, open source, кросс-платформенный (Win, Linux, Mac, WinMobile, Android, Simbian )

  • документация на русском.

  • Позволяет быстро создать прототип не только диалогов, но и сюжета любой сложности в виде готовой текстовой игры.

  • Развитые средства отладки.

Недостатки:

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

  • Требует некоторые начальные навыки программирования.



2) Chat-Mapper.  Это специализированная коммерческая программа. Базовый вариант бесплатен, однако не все возможности доступны. Позволяет визуально проектировать сеть ключевых моментов беседы а также программировать логику с помощью тех же скриптов на Lua.  Есть "симулятор", в котором можно тестировать диалоги, словно в игре.Поддерживаются развитые средства экспорта в xml, Exel, работа с локализациями, привязка озвучки и многое другое, но за всё это придётся уже заплатить деньги ($59.95 и больше).



Достоинства:

  • Понятный интерфейс.

  • Визуальное проектирование дерева диалогов.

  • Режим симуляции беседы

  • Управление беседой с помощью Lua-скриптов

  • Экспорт в разные форматы, возможность создать свой модуль экспорта.

  • Поддержка локализаций.


Недостатки:

  • Windows only,

  • Экспорт недоступен в бесплатной версии

  • xornot

Интергалактический кролик Юрик

В этой сумбурной статье хочу поделиться опытом создания игры "Интергалактический кролик Юрик" (http://yourik.sourceforge.net/index-ru.html). Опыт этот не стоит наследовать, потому что "Юрик" создавался так, как, скорее всего, не нужно делать игры.

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

Меня пугало вот что - редактор уровней. Я примерно соображал, как делать движок, и эта задача была для меня интересна. А вот редактор уровней - программа, где создаются карты уровней, то есть расстановка игровых объектов и прочее, прочее - казался, и по сей день считается мною - программой нудной, которую писать скучно, это не имеет ничего общество с творчеством.

Можно ли обойтись без редактора уровней? Да, если наполнение уровней идет на программном уровне, то есть совершается во время выполнения программы, а не человеком заранее. Например, в редакторе уровней бы ставите мышью, грубо говоря, кирпичики стен, полов и так далее. Их же можно расставить и программно, по такому-то алгоритму (где проверяется, сможет ли персонаж игрока пройти и не застрять). То же с врагами - их можно расставить по уровню заранее, в редакторе. А можно - программно, случайным образом.

Жанр. Жанр я выбрал самый простой - одноэкранная бродилка-стелялка. Без стен - то есть всё игровое сквозное, преград нет. Как в Диггере.

Всегда надо начинать с простого - так проще и быстрее добиться работоспособности, иначе вы погрязнете в паутине нерабочих частей игры и потеряете к ней интерес.

Я решил делать игру многоплатформенной и на своем движке. Язык программирования - конечно же, самый лаконичный и мощный - C++. А вот с тулкитом - основной библиотекой, на которой зиждется программа - я... Не ошибся, но - Qt не предназначена для динамичных игр. Игровой цикл с привязкой к кадрам в секунду на Qt - это издевательство. Тем не менее, мне был привычен Qt, не хотелось тратить время на изучение других тулкитов, поэтому - выбрал Qt. Повторюсь - я поставил себе задачу написать игру как можно быстрее. Например за месяц.

Сейчас я работаю над игрой "Юрик 2", она уже использует другой тулкит - SDL, заточенный нарочно для игр. Но и работа затянулась.

Что такое игровой цикл? Мы повторяем выполнение одного и того же алгоритма столько-то раз в секунду - по крайней мере, пытаемся уложить его в выполнение в определенные временные рамки. Что за алгоритм?

Для бродилки, леталки, стрелялки он прост:

Считываем состояние клавиатуры, джойстика, мыши.

Изменяем в соответствии с ними направление движения персонажа.

Вычисляем перемещения врагов (они движутся в зависимости от разных алгоритмов. Скажем, если персонаж близко - враг "видит" его и начинает нападение или стреляет).

Вычисляем столкновения персонажа с врагами, с предметами (например призами, пополнялками жизни и так далее), выполняем действия, которые четко заданы в связи с такими-то событиями. Например, персонаж столкнулся с объектом-сердечком, и у персонажа добавляется 1 пункт жизни.

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

Выводим буфер на настоящий экран.

Вот так грубо, упрощенно выглядит каждая итерация игрового цикла. Хотим 50 кадров в секунду - стараемся прокрутить 50 таких итераций в секунду. Но итерации жрут вычислительные ресурсы и не всегда процессор успевает выполнить заданное количество итераций в запланированное время. Тогда начинаются тормоза - либо "лаги" - в зависимости от алгоритмов.

Так вот в Qt выполнение игрового цикла привязывается к событию таймера. Что это значит? Переводя на человеческий язык - вот у вас есть будильник, который звонит 50 раз в секунду, и по каждому звонку выполняется такое-то действие. В нашем случае - итерация игрового цикла.

В SDL иначе - "бежит" цикл, а в него до или после каждой итерации вставляется паузы, по длительности рассчитанные так, чтобы общее время выполнения итераций плюс эти паузы дали секунду времени. Сколько-то миллисекунд потратится на выполнение алгоритмов в каждой итерации, столько-то - на паузы. Этот способ более правильный. А в Qt я просто напрягал таймер столько-то раз в секунду вызывать по итерации цикла.

Также я решил использовать оконный режим и вывод через OpenGL. Иначе "таймерный" цикл не успел бы отрисовываться.

Для вывода звука я использовал SDL (и её дополнение SDL_Mixer), написав под нее удобную надстройку, которая позволяла загружать файлы озвучки, музыку и воспроизводить их. Звуки я подготавливал в звуковом редакторе собственной разработки - EKO (http://eko.sourceforge.net/index-ru.html). Часть звуков мне помогли записать родственники и друзья, часть я синтезировал. Использовался кроме прочего речевой синтезатор старого компьютера Amiga, а точнее - эмулятор этого компьютера. У этого речевого синтезатора очень вкусный тембр - вы могли слышать такой роботический голос в песнях стиля евро-поп в 90-тых годов, например в начале "It's my life" Dr.Alben'а, там где "Positive selected, positive selected...". Было еще довольно любопытно читать звуковой вывод эмулятора - он писал в PCM с каким-то чудовищным DC-смещением, т.е. волновая форма сигнала была смещена относительно оси, и мне пришлось дописывать в EKO функцию исправления смещения DC. Вся озвучка в игре была переведена в формат Ogg - дешево и сердито. Музыку я написал под Windows в программе Reaper, используя MIDI-клавиатуру и виртуальные синтезаторы.


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

Внутренне игра про Юрика представляла собой уровни, связанные между собой. Всё было уровнями. Заставка - уровень, конец игры - уровень. С каждого уровня было две внутренние ссылки - на другой уровень при прохождении текущего уровня, и на другой уровень при гибели персонажа. В каждом уровне был определенный набор персонажей, а также привязанный уровень - заставка, показываемая перед игровым уровнем.

Анимированные заставки с титрами - отдельная тема. Игровой цикл в "Юрике" два режима - игровой и показа заставок. Для заставок я придумал свой скриптовый язык, причем заставки могут быть переведены на любой язык. В составе "Юрика" идут русские и английские заставки.

Но вернемся к уровням. У каждого уровня есть свой логический переключатель прохождения. Я ввел разные переключатели. В одном уровне такой переключатель - убить столько-то врагов. В другом - спасти столько-то животных. В третьем - подобрать столько-то бочек с горючим. Как только переключатель переключается, происходит чтение нового уровня и обработка уже его в игровом цикле.

Враги. За перемещение врагов отвечают довольно простые алгоритмы. На направление движения влияет, с такой-то степенью вероятности, генератор псевдослучайных чисел.

Боссы - те же враги, только большие и покрепче. На каждом уровне есть босс. Мне нравятся игры с огромными, на весь экран, боссами. В "Юрике" они не на весь экран, но всё равно большие.

Анимация персонажей. В "Юрике" используется спрайтовая анимация. Спрайт - это набор кадриков с разными фазами движения. При этом, для движения влево - один спрайт, вправо - другой, и так далее. Взрывы - тоже спрайты. По ту сторону экрана взрыв происходит так - с карты уровня удаляется взорванный объект (например враг), на его место помещается объект-взрыв с закрепленным за ним спрайтом, и пускается на воспроизведение звук.

Звуки. Подобно тому, как за персонажами закреплены взрывы, закреплены также и звуки. Каждый персонаж имеет ссылки на звуки стрельбы, своей смерти и тому подобное. Я сделал так, чтобы не по одному звучку на каждое событие, а по несколько, и вариант выбирается случайным образом. То же касается и взрывов - взрывы разные, случайным образом.

Графический формат кадриков спрайтов - PNG. PNG хорош тем, что поддерживает альфа-канал - прозрачность фона под нарисованным объектом. Почти вся графика, кроме вражеского космолета, создана мною в свободном векторном редакторе Inkscape, а потом отрендерена в PNG. Космолет я нарисовал в Xara for Linux. Какие-то монтажные штуки я делал иногда в GIMP. Но в целом хватило бы и одного Inkscape. Это очень мощная программа, хотя несколько тормозная при сложных рисунках.

Самое сложное при создании игры было наладить скорости персонажей, скорости отображения титров, и сложность игры. Настройка баланса между смертоносностью врагов и живучестью Юрика. Я признал игру годной к выпуску, когда сам прошел ее от начала до конца. И конечно, у меня для проверки уровней были возможности включать любой уровень и бессмертие.

Я рассчитывал сложность "Юрика" на игроков старой школы, 80-90 годов, поэтому многим современным игрокам игра показалась слишком сложной. В "Юрике" большое значение имеет опыт игрока, то есть когда вы однажды поняли, какую тактику использовать на таком-то уровне, вы легко его пройдете и позже.

Под игру был создан сайт (http://yourik.sourceforge.net/index-ru.html), в сеть я выложил исходники (без труда компилирующиеся в Linux) и 32-битную сборку под Windows, с которой сам немало повозился - уже точно не помню, с чем возникли трудности, кажется с SDL_Mixer.

Исходники, звуки и графика отданы мною в общественное достояние (public domain), то есть вообще без всякой лицензии и копирайтов. Что с ними хотите, то и делайте. Я лелеял надежду, что на основе движка энтузиастами будут созданы другие игры - увы, этого не произошло.

Вскоре после выпуска первого Юрика, я взялся за вторую часть - уже с редактором уровней, в другом жанре и весовой категории. Покамест кроме демки, где Юрик летает по уровню мимо деревьев, на фоне красивых пушистых облаков, мне показать нечего. Технические данные этого проекта, которым я хочу снова заняться ближе к весне, таковы - язык С++, тулкит SDL, система сборки Scons. Движок уже сейчас работает нормально под Linux и Windows в полноэкранном режиме. Редактор уровней пишется тоже на C++, но с тулкитом Qt. Вот демка движка - на самом деле всё плавно, это видео так рвано записалось: