Не так давно, на заре этого тысячелетия, холодным ноябрьским днем 2004го я сел писать эмулятор сервера для некой онлайн игры. Писалось мне весьма хорошо, на радующем глаз C# и .Net Framework версии 1.1. Особых целей перед собой я не ставил, а опыт имел сравнительно небольшой. По какой-то причине сообщество оценило эту поделку (может, потому что она появилась раньше официального старта основной игры?) и через несколько месяцев я столкнулся с взрывным ростом онлайна, а заодно и серьезными проблемами производительности. Проект прожил 6+ лет, достиг заметных высот (2500 онлайна в пике, порядка 20000 MAU), а затем и почил в бозе. И вот спустя полтора десятилетия я решил сделать собственную ММО игру на тех же “проверенных временем” наработках и столкнулся с аналогичными же проблемами, не смотря на то, что они были уже единожды мною решены.

Недавно мой знакомый Karl (имя изменено) проходил собеседование на должность DevOps и обратился ко мне с просьбой проверить его решение. Я почитал условие задачи и решил, что из нее бы вышел неплохой тест, поэтому немного расширил задачу и написал свою реализацию, а заодно попросил коллегу Alex подумать о своей реализации. Когда все три варианта были готовы, я сделал еще две сравнительные версии на C# и сел писать эту статью. Задача довольно проста, а соискатели находятся на неких ступенях эволюции из админов в программисты, которые я и хотел оценить.

Кому интересны грязные детали, необъективные тесты и субъективные оценки — прошу под кат.

Как-то раз возник у меня диспут с хабраюзером ZimM по поводу безшейдерного 2D движка: я утверждал, что для простых 2D игр шейдеры не обязательны, почти все эффекты можно сделать спрайтами, его же позиция была обратной. Я не раз в уме возвращался к этому спору и придумывал задачи, не реализуемые на первый взгляд без шейдеров, и именно решение одной такой задачи и привело к созданию игры, где игрок управляет жидкостью наклоном телефона.

Три пути у человека, чтобы разумно поступать:
первый, самый благородный, — размышление;
второй, самый легкий, — подражание;
третий, самый горький, — опыт.
Конфуций

Однажды прохладным весенним вечером 2013 года захотелось мне сделать собственный аналог приятнейшей старой игры Scorched Earth, но с разными вытребеньками. Под хорошее настроение и заводную музыку я бросился кодить на первом попавшемся под руки IDE и фреймворке. По злой иронии это оказался WFP для Windows 8 Store. А вот для полета снаряда и реакции окружения я взял Farseer Engine — C# порт Box2D.
Сам уже не помню, как от идеи разрушаемой земли и баллистических ракет я перешел к катапультам, строениям из блоков и монолитному ландшафту. Так и началась двулетняя история моего клона Angry Birds.

В далеком 1998 году я пытался сделать свою игру с OpenGL. Разработка с трудом дошла до альфы и была заброшена, но что особо запомнилось, так это как удобно было делать под GL интерфейсы — ортогональная проекция, пара трансформаций, биндинг нескольких вершин с GL_TRIANGLE_STRIP и у нас уже есть кнопка. И вот, спустя шестнадцать лет и занимаясь мобильным игростроем я столкнулся с таким же подходом в OpenGL ES 1.*, разве что 2D текстуры без вращений можно теперь рисовать через glDrawTexfOES.
Я поддерживал несколько проектов, сделанных по этому принципу и понемногу в голове выстроился коварный план: сделать кросс-платформенную 2D игру на мобильных с OpenGL ES и на C#, а на десктопах с обычным OpenGL. Цели я добился не с первого раза и было с этим много проблем, но в результате очередной проект у меня работает без изменений бизнес-логики на iOS, Android, BlackBerry, Windows XP/7, Mac OS X, Linux, ReactOS, Windows 8, Windows Phone 8.1. Материала набралось на много статей, но в этот раз я расскажу именно о поддержке Windows Runtime.

Как-то раз Мигель…
_{(Хотя нет, история не совсем о нем, попробую начать иначе)}
Однажды в мире Open Source…
_{(Тоже мимо, OSS в истории затронуто лишь частично)}
Когда жажду наживы называют здравым смыслом, начинается обман.
_{(Почти афоризм)}

Предыстория

Стукнуло мне в голову написать программу под Мак на C#. Я поблагодарил Мигеля де Икасу за отличный Open Source проект Mono, воздал хвалу за его же библиотеку MonoMac, чуть ругнулся на сыроватый MonoDevelop и принялся за работу. Через некое время был оплачен аккаунт в AppStore, программа была в шаге от завершения, когда начался большой проект по основной работе и ее пришлось отложить. И вот через год пришло сообщение, что пустующий аккаунт в AppStore будет закрыт через 30 дней — это был знак, что надо что-то делать. MonoDevelop, обновившийся сам до Xamarin Studio, предложил сразу проект MonoMac преобразовать в Xamarin.Mac и повел меня на сайт, где было предложено купить этот самый Xamarin.Mac всего за $999, иначе деплоймент в AppStore будет невозможен.

Как-то так вышло, что завелся у меня Windows 8 планшет. Не очень удачная модель — громоздкий как помощник, слабоватый как рабочая станция, но зато с стилусом, а самое важное, с 32-битной Win32 системой. Имея некое количество старых игр с распродаж GOG и Steam, я планировал как-нибудь засесть с этой таблеткой и переиграть все, что можно и нельзя. Но вот как-то не хватало времени и настроения, да еще и пробные запуски показали, что играть надо с мышью — курсор от тач-скрина убегал неизвестно куда, да и правый клик долгим нажатием был бы откровенно неудобным. Планшет пылился пол-года в углу до недавней раздачи Fallout от GOG и эта раздача подтолкнула меня к действию. Начинался вечер пятницы, планшет обзавелся USB мышью, а я устроился поудобнее на диване и начал по списку с самого верха — с Arcanum.
Через пол-часа создания персонажа (а ведь это дело очень важное и ответственное!) левая рука с трудом держала устройство, а запястье правой подозрительно начало тянуть, намекая о туннельном синдроме и прочих радостях неудобного хвата. Вспомнив нехорошим словом разработчиков некой эргономичной складывающейся мыши, я полез искать драйвера, патчи или еще хоть что-то, чтобы играть с тачскрина или хотя бы стилуса.
Патчей не нашлось. Единственный похожий драйвер был платным и без пробного режима. Вот в этот момент в голову и пришла идиотская (это я теперь понимаю!) мысль — «там ведь наверняка приходит какой-то WM_TOUCH и неправильно преобразуется в WM_MOUSEMOVE»… Забегая вперед, Арканум теперь у меня полностью управляется с тачскрина, правда, выходные закончились и больше хочется спать, чем играть.

Как и многие программисты, я с опаской относился (и отношусь) к Windows 8, но не удержался попробовать написать пару программ для Windows Store. Все-таки, это модная тенденция: .Net 4.5, C# 5, XAML.

Как раз в эти дни, 4го декабря, мне попалась на глаза статья про конкурс приложений для W8 от Microsoft. Выкладывать экспериментальные программы было как-то не серьезно (хотя маркет такими поделками буквально переполнен), потому я решился портировать достаточно масштабный проект с MonoTouch и iOS. Запаситесь попкорном, потому как кроме программистских деталей тут будет и комедия, и драма, и жизненный финал.

О проекте AppSurfer на Хабре упоминали, когда он был в бета-стадии, а теперь хочу рассказать несколько технических деталей об актуальной версии. Вкратце, проект дает возможность «потрогать» Android программу через браузер. В предыдущей статье его назвали «YouTube для Android-приложений» и это на 100% верное определение.

Регистрация открытая, разработчики сами выкладывают свои .apk файлы. Приложение обязательно должно быть в Google Play, оттуда берутся мета-данные, иконка, скриншоты и описание. Программы выполняются в виртуальной среде и их изображение передается на Flash-плеер в браузере.

Конечно же, формат JPEG не поддерживает прозрачность, но сама идея использовать JPEG вместо PNG для прозрачных текстур будоражит умы довольно давно. Камрад PaulZi не так давно предложил использовать для HTML формат SVG, в котором хранится само изображение и маска. Jim Studt предлагает использовать EXIF поля в JPEG и хранить там маски, а отображать на веб-странице с помощью Canvas.
Оба метода относительно сложны для использования, да и рассчитаны на веб, потому я остановился на самом простом варианте: хранить отдельно lossy JPEG для RGB и lossless маску в PNG, а совмещать их на этапе получения UIImage в программе. Сразу хочу сказать, что пишу на MonoTouch, потому код привожу на C#, хотя в ObjC это делается почти точно так же, с учетом синтаксиса.

После поста о подходе Apple к кодированию видео в JPEG, решил рассказать о своем подобном «велосипеде» под Android.

В своем мобильном проекте решили мы сделать превьюшки оружия не статической картинкой, а видео. Подразумевалось, что художники нарисуют красивые анимации, может даже в 3д, но что-то не сложилось и нам выдали простейшие зацикленные 1-1.5 секундные ролики в разрешении 256х256. В iOS версию они встроились замечательно, а вот в Android пришлось повоевать с MediaPlayer и SurfaceView, но все-равно получились некоторые «корявости» — содержимое SurfaceView не перемещалось вслед за родительским View, была заметная пауза при воспроизведении, и пр.

Разумным решением было бы разбить анимации на кадры и оформить в xml для AnimationDrawable, но для 15 видов оружия это значило бы мусорку из 5000+ кадров по 10-15 кб каждый. Потому была сделана своя реализация AnimationDrawable, работающая с sprite sheet и относительно быстрый метод конверсии видео в такой формат.

Иногда надо записать демо работы программы, но под руками нет подходящих инструментов. Более того, бесплатных утилит для этих целей вообще не найти, а платные еще и не факт, что справятся как надо. Как поправили меня в коментариях, обычная версия QuickTime Player отлично пишет видео. Дальше рекомендуется читать только любителям open-source и необычных решений.
В моем случае возникла необходимость записать работу игры на симуляторе iPhone и Android. Программист внутри меня сразу предложил написать кучу кода, как под iOS/Android, так и под сам Мак, дампить кадры через OpenGL и пр. Остановив эти позывы, я таки решил найти готовые решения, а затем и оформить тут статью, как памятку.

Иногда программисты изобретают свои «велосипеды», но действительно ли это плохо, особенно если творение не отличимо от оригинала, а автор получает бесценный опыт?

Эта история началась чуть более года назад с появлением у моей супруги современного смартфона. Она попросила найти пасьянс «Косынку», такой же как был когда-то на настольной Windows. Просмотрев десяток программ, я был неприятно удивлен — почти везде было неудобное управление, спорные картинки карт, море дополнительных наворотов вроде 250 пасьянсов в одном, установки фотографии на рубашку и блекджека с блудницами. В результате, выбрали один из более-менее годных вариантов и на какое-то время об этом забыли.
Пролетел год и я начал писать программы для мобильных. При этом ребром стал вопрос кросс-платформенности, отладки in-app покупок, подготовки контента под разные платформы. Была мысль сделать для пробы пера «Тетрис» или очередной калькулятор, но все же в качестве «велосипеда» я выбрал «Косынку». Идейным стрежнем проекта стало максимально точное повторение старого, доброго пасьянса из набора игр Windows.

При сборке приложений под iOS для оптимизации ресурсов используется скрипт iphoneos-optimize из набора XCode. Работает он отлично, но если копнуть поглубже, то становится ясно, что некоторые файлы не пережимаются, а другие хоть и немного уменьшаются, но все-равно далеки от идеала. Можно сказать, что задача скрипта сделать файлы более совместимыми с iPhone, чтобы они быстрее читались или распаковывались, но скорее всего это имело смысл лишь на старых iPhone 1 и иже с ними, а уже на процессорах 1ГГц с ARM 7 это откровенно не актуально.
С помощью простых оптимизаций и парочки программ из набора MacPorts можно добиться существенного уменьшения PNG и JPG картинок в конечной программе, а при желании и других видов данных.