Unity + winphone = ?

UPD: всех мусульман с праздником ураза-байрам! По этому случаю татарский словарь на ios в течение трех дней будет бесплатным. Православных поздравляем с днем крещением Руси и тоже советуем скачать этот словарик :)

Ок, опыт по разработке и паблишингу win phone приложений появился.

Я научился делать как нативные приложения (к примеру, на основе дефолтного шаблона сделан словарь lugat, а также мультипайвотный турецко-русский и русско-турецкий словарь), так и unity игр. При разработке нативных приложений надо следовать тем же паттернам, что при разработке на iOS. Если понимаешь, что такое делегат и как работает data provider, проблем не будет. Однако верстка страницы больше напоминает андроид - там больше работаешь вручную с XML-ками, нежели тянешь курсором за констрейны.

Как и ожидалось, больше всего проблем было с юнити. Процесс портирования пробовали на старом бедном матаке, который уже пережил 100к закачек на андроиде и только недавно вышел на iOS. Не хочется особо рассусоливать, пройдемся списком по граблям, которые встретил в процессе:

Успешная игра - каждому по приоритету

Мою квартиру обокрали. Тупо взломали дверь ломом. Видно, взломали первую попавшуюся квартиру, все шкафчики открыты - видимо, искали повсюду. Самое странное - сперли только ноутбук. Хотя у меня, гиканутого нерда, окулусов, райзер хидр и прочей техники было на гораздо большую сумму. Люди не знали их стоимость, поэтому сперли только один ноутбук - можно сказать, легко отделался.


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

Совсем недавно нам удалось реализовать игру, которая подходит под мое определение успешности, как программиста. Нет, это не road smash, хотя, судя по статистике, она очень понравилась пользователям и наверняка приносит хороший доход.

Игра называется Clumsy Fino (тыц для ios), это очередной клон Flappy Bird с респавном и дракончиком. Вроде ничего примечательного, но игра успешна. Объясню почему:

1. У нас отличная команда - множество непересекающихся скиллов. Альберт Александровский взял на себя роль издателя, он занимался продвижением, поиском подходящих запросов, делал завораживающие картинки. Игорь Фомичев делал игровую часть, делал баланс. Я прикручивал плагины, занимался неигровой частью. Каждый занимался тем, что он лучше всего умеет. В условиях "экстремальной разработки" эта тактика сыграла как нельзя лучше.
2. С самого начала мы решили делать максимально быстро. Первая версия игры была сделана за два дня по вечерам, содержала в себе все мастхэвы и вылита в сторы. Это была самая продуктивная итерация на моей памяти.
3. Вторая итерация заняла чуть больше времени(пять дней "грязного времени", где-то три человекодня на всех), за это время мы полностью обновили GUI, добавили важную фичу - респавн птицы при смерти. После апдейта количество скачиваний удвоилось (спасибо, Альберт!), а игровая сессия стала больше в среднем на три минуты (спасибо, Игорь).
4. В разработке не было факапов. Вообще. Причины две: 
1. мы делали только те фичи, которые казались нам нужными. Те, которые не очень привлекательны игрокам или трудозатратны - мы не делали. Наконец-то смогли применить принцип Парето.
2. Никто не лез в чужую область, каждый делал то, что умел лучше всего. Минимум ресерча, просто берешь и получаешь результат. А через четыре часа люди радуются этому результату.
5. Не знаю, как остальные ребята, лично я получил огромное удовольствие. Это было подобно очень короткому кэмпу, где ты просто делаешь то, что тебе нравится. Результат не заставил себя ждать. 
6. Эта игра уже окупила наши трудозатраты. Доход до сих пор растет :)

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

За ноутбук не сильно обидно - там стоял deep freeze, хрен они там смогут им воспользоваться. При более тщательной ревизии всех вещей оказалось, что эти уроды сперли купленный вчера торт! Спереть ноутбук и торт вместо того, чтобы спереть дорогостоящую технику? У меня нет слов. 

5 things you need to implement in any mobile game

русская версия - здесь

I have three posts in drafts(called "You don't need server" and "3 reasons to switch from Asset Server", "Execute impossible to pardon: how to deal with hackers"), but decided to write this one just because it seems more timely than others.

We had discussion with Yuri about what makes any game perfect and what features must be implemented and come up with some common and must-have features:

• in-app-purchases. No comments here. If you want to make money from your game, you'd better have well-tested, stable in-apps;
• analytics. The thing is you can not predict user behaviour unless you have any clue what your user is doing in the game. And it's better to have as much information as possible - you know where is your problem in your game mechanics and can easily fix it up;
• local and remote push notifications. We didn't implement them in the first releases of Road Smash and we feel regret about it. What is the easiest way to let the users play updated game? Obviously, push notifications.I know that users may hate pushes and remove your app just because they are got annoyed by your app, but in 70% it works.
• Anticheat protection. You know, cheaters always exist, especially on android and you need to prevent your game from being hacked. Somebody may say that you need to protect everything, somebody have an opinion that you need to give up on hackers and let them play. I think that hackers wouldn't pay. They would keep hacking the game until they find something or even delete it from their devices, but they would never pay. So I came up with the decision here: protect only that things that cost money or may affect other users. In business terms there are two most important things for developer: users that bring money. When I say money, I mean in-apps, when I say affect other users, I mean scoreboard, social, competition parts of your game. And you need to keep tiny balance between letting gamers play comfortably and prevent players from stealing your money.
• Ads. I underestimated role of ads, thought it's annoying and may push your user away. But I was wrong. Firstly, you can integrate ads, so they will become part of your gameplay. Users will want to see some ads just to get some goods instead. And of course, it is a great chance to  get money from users that will never pay :)

The main purpose of any game is to have a lot of users in game and keep them as long as long as possible, letting them pay for any reason. In that meaning these five features described must be implemented, well-tested as soon as possible.

And to make this post more concrete, I have some links to assets to share with you to get that features implemented in the easiest way.

• in-apps: use unibill. It supports app store, google play, windows store out-of-box, including receipts, subscriptions, etc. Must-have!
• analytics: there's a wonderful and free plugin, called GameAnalytics. It supports events, heat maps, gameplay stats. If you are fan of old-school analytics, you may check out for my wrapper to Flurry plugin in my github repository, I'll push all the code as soon as I find free time for it. 
• push notification: there are too many good plugins in assets, so I don't know what's the best option here. I'd recommend pushwoosh service, because it provides a lot of features out-of-box, but let me leave this topic open.
• anticheat: well... there's no common solution as it really depends on what kind of game you are working on. Maybe some kind of playerprefs encryption, in-apps encryption? Did I miss something?
• ads: there is a bunch of different options: admob, tapjoy, adcolony, applifier. Some of them provide banner and image ads, some of them kind of video or partnership ads. Choose one you like the most.

Unity Continuous Integration

And finally Unity Continuous Integration (CI) plugin is on Unity Asset Store! Check it out: https://www.assetstore.unity3d.com/#/content/12695.

I spent a day setting up Jenkins build machine on Road Smash project and spent one more day to unify builder script and writing documentation, so I can use it on any unity project with any CI framework and any CVS systems, including asset server, git, svn. It works out-of-box, the only thing you need is to call the right method(like BuildAndroid, BuildIOS) from command line(OSX, Windows).

For now Unity CI supports:

• iOS build
• Android builds (including different builds for different textures format, including ATC, ETC, DXT & PVRTC). You can call a method to build 5 different apks, which will support different textures from AndroidManifest.xml and may be uploaded to Google Play as multiple apks.

I didn't include changing version code to plugin, because every project may have its own policy and I may break it, but it is really easy to add there. I'll write another post about all android building stuff later.

I'm planning to include unit-testing plugin to CI and make it portable. I'll finish it up as soon as I'll have a free time for it.

P.S. Unity Technologies rejected my Flurry plugin(full iOS & Android, Windows Phone beta support) for its own internal business reasons. Is anybody interested in it?

Баг шейдера при операции mul

Натолкнулись на баг в шейдере unity:

• шейдер ломается частично, а именно: чем ярче пиксель, тем больше он стробит (если оттенок черного - все норм, ярче - становится заметней). То есть шейдер работает, fallback-a не происходит!
• происходит только при операции умножения матрицы 4x4 на вектор4.
• воспроизводится только на адрено устройствах. 

И это при условии, что мы потом отбрасываем последнюю часть и приводим полученный ответ к vector3.

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

В общем, у кого стробление пикселей в шейдере, напишите собственный mul (благо, это просто несколько операций dot).

Unity3d optimization in one presentation

Let me just leave this here:
presentation

... and that links...

Practical Guide to Optimization for Mobiles (Unity Manual)
Optimizing Graphics Performance (Unity Manual)
Profiler (Unity Manual)

ShadowGun: Optimizing for Mobile Sample Level (Unity Blog)
“Fast Mobile Shaders” talk at SIGGRAPH 2011 (Unity Blog) - highly recommend to anyone who writes unity shaders
http://malideveloper.arm.com/
OpenGL ES 3.0 Developer Resources (Mali Developer Center) - now it's not widespread, but it seems to be very popular and effective in near future!
ASTC Texture Compression: ARM Pushes the Envelope in Graphics Technology (ARM Blogs)

Optimize performance in Unity3d: practical notes

(Russian post goes here)
I wrote an article in russian about unity performance optimization recently. In this topic I want to share some small, but efficient practical tips with you. Here we go:

• if you're running out of memory, use proper texture compression. PVRTC is acceptable for iOS, DXT for android. And don't forget about mip-maps. I know, it gonna increase binary size by 30%, but it's worth it. Don't be so modest to limit max size to textures. 
• If you don't need shadows in renderers (for example, in UI or something), just uncheck "Receive shadows" & "Cast shadows" options. They are always on by default.
• Don't forget about batching. And yes, static batching allows much more than dynamic, so you don't move object, mark it as static. If you want to combine meshes runtime, use StaticBatchingUtility.Combine.

• Take into account renderer settings, physics settings of project (Edit->Project settings)
• Anti-aliasing, texture quality, shadows and vsync have many options. Just experiment with them to gain best performance/quality.
• Uncheck layer collision checks you don't need to calculate.
• If you don't really need physics, change fixed timestep.
• Don't move static objects. 
• Design your level, so your camera will not take a lot of objects, then camera culling will save a lot of frames for you.
• Mesh collider checks are very expensive! It's better to use double-check technique: firstly make a capsule or box collider and check with it's collision, then check with mesh collider.
• Lights. Know the difference between point & directional, use them properly. 
• Cache  transform, collider, rigidbody. We use CachedMonoBehaviour in our projects and happy with that (P.S. From 4.1 Unity did a lot of work with GetComponent optimization, but CachedMonoBehaviour is still faster).

You may achieve better results if you know instruments you use. These tips are really easy to use and sometimes they give more performance than it's expected. Use it and know, premature optimization is root of all evil.

P.S. We are applying all this tips in game named technoball, so please free to try it and tell me what you think about it.
P.P.S We made a lot of work and prepared an awesome update, stay in touch!

Почему Unity?

Меня попросили написать короткую статью о том, зачем нужен unity3d и почему я пользуюсь именно им. Решил поделиться своими мыслями здесь, в блоге и постраться не создать очередной холливарной статьи :)

Рынок мобильных приложений, в частности, мобильного гейм-дева, такой, как сейчас, появился совсем недавно - в 2008-2009 году, почти сразу после появления революционного по тем меркам гаджета под названием iphone. А поскольку игры на мобильных начали пользоваться бешенным спросом, то программисты начали делать все, чтобы этот спрос удовлетворить. Совсем скоро начали появляться движки для создания мобильных игр, такие как shiva3d, cocos2d, airplay sdk(сейчас marmalade), corona sdk, unreal engine для мобилок(ограниченный udk), unity3d и так далее. У меня был совсем маленький опыт разработки под marmalade, немножко поигрался с udk, но больше всего мне понравился unity3d.

Чем же привлекателен лично для меня unity3d:

All you need to know about serialization in Unity3D

upd: video is removed, so check out this link.

Some materials from knowledge sharing seminar

Two months ago we started our unity knowledge sharing seminars. I forgot to share materials I promised to, so let me do it here.


2D UI - NGUI (Presentation on russian)

2D in Unity3D from Рустам Ганеев

Useful links:

• NGUI:  http://www.tasharen.com/?page_id=140
• Optimizations for mobile devices: http://docs.unity3d.com/Documentation/Manual/iphone-OptimizedGraphicsMethods.html
• Developing apps for different resolutions (russian): http://rustam-kot.blogspot.ru/2013/03/blog-post_25.html
• Cool plugin for NGUI speeds up development and make life easier: http://u3d.as/content/monster-juice/fast-gui-for-ngui/3vJ

Unity shaders (Presentation on russian)

Shaders from Рустам Ганеев

Useful links:

• http://docs.unity3d.com/Documentation/Components/SL-Reference.html
• http://http.developer.nvidia.com/CgTutorial/cg_tutorial_chapter01.html
• http://cgcookie.com/unity/category/tutorials/shaders-tutorials/

UPD: Dustin Lee, the Unity evangelist kindly shared awesome slides about shaders, just check it out:

Unity Shader System Introduction from Lee Dustin


UPD #2:

Habr: 2D in Unity3D http://habrahabr.ru/post/122197/

46 advices on 2D game development. http://sicklebrick.com/?p=411

Orthelo 2D. http://www.wyrmtale.com/products/unity3d-components/orthello

SM1. http://wiki.unity3d.com/index.php?title=SpriteManager

SM2. http://www.anbsoft.com/middleware/sm2/

ex2D (http://www.ex-dev.com/ex2d/)

2D Toolkit (http://unikronsoftware.com/2dtoolkit/)

Dynamic texts in ngui

The only problem I have to deal with 2D UI in NGUI plugin is text fonts. In details, there's a bunch of problems:

• Dynamic font support (UPD: from NGUI 2.5 dynamic fonts are supported out-of-box)
• Localization(arabic, hebrew languages, chinese etc).
• Input texts

As I'm working on localization in deep, I found some useful things to solve problems described above:

• for dynamic font, use https://github.com/imkira/unity-sysfont. It seems to be out-of-date (it hasn't been updated for 9 months), but it works and you need just to tweak it for youself. Maybe I'll finish it in holidays.
• for chinese, japanese dynamic fonts works ok, use plugin above. If you intent to support arabic languages,  use http://u3d.as/content/abdullah-konash/unity-arabic-support/2B8. This asset allows you to write in rtl mode. Now I'm looking for hebrew plugin, or if I find someone who can read hebrew, I'll write it for myself. 
• Situation about input text is troublesome. Changing uiinput component will cause problems with supporting and I don't like to do it. But there's no other way to cope with it.

Особенности национальной верстки или привет зоопарк устройств

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

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

• (дизайнерам) Забудьте о pixel-perfect верстке. Ее не будет. Но именно благодаря этому на всех экранах все будет выглядеть одинаково.
• (программистам) Свыкнитесь, что будут грязные хаки. Это вначале все будет идти гладко да хорошо, а потом вдруг запустишь аpk на 320x240 и удивляешься, что все друг на друга наплыло.

А теперь описание процесса, как мы достигаем вселенского счастья:

• Есть UI (кнопки, слайдеры, менюшки), а есть бэкграунд(бэк). Ну так вот, бэк - это просто картинка(чаще всего однородная) на заднем фоне. Она нужна для того, чтобы по бокам не было черных фонов.
• Мы делаем картинку бэка максимально большим и широким, а потом на каждом девайсе скейлим вниз пропорционально по высоте. К примеру, у нас бэк размером 2764 x1536.  На айфоне 5 отрисуется центральные 2726x640 пикселей. Таким образом, получается, что на самом деле наш бэк будет выходить за границы отрисовки. Скейл вверх нежелателен, но если есть ограничение по памяти, то тут никуда не денешься - никто не даст тебе рисовать картинки 4096x4096.
• Бэк центрируется. Ваш кэп.
• В нарезке UI сюрпризов нет, нарезаем по обычному.
• При верстке UI абсолютно все располагаем относительно UIAnchor-ов. Каждый элемент экрана должен принадлежать к какой-то отдельной части. Да, на каждый чих индивидуального пространства создаем отдельный якорь. Типично используемых якорей хотя не так уж и много: центр, левый верхний угол, правый верхний угол, нижние углы по краям, верх и низ. Остальные используются редко.

Да, еще одно ограничение: надо уложиться в 50МБ выходного файла. Это было интро, а теперь требования и настоятельные рекомендации:

• (дизайнерам) Размеры бэкграундов: 1460x768(HD), 1090x460(SD).
• (дизайнерам) Верстка под экраны: 1024x768(HD), 2048x1536(если совсем не жалко памяти). 
• (дизайнерам) Формат картинок: png
• (дизайнерам) По максимуму избегать альфы (особенность unity - чем больше площадь наложения альф, тем сильнее просаживается fps)
• (дизайнерам) По максимуму избегать градиента (из-за проблем со скейлом)
• (дизайнерам) По возможности, используем nine-patch везде, где только можно.
• (дизайнерам) Шрифты в растровом формате. Более подробно: на ютубе
• (программистам) UI элементы пакуем в одну текстуру с помощью NGUI, бэки оставляем как отдельные картинки(преимущество от запаковки бэков теряется при огромном размере атласа).
• (программистам) Сжатие текстур: PVRTC для ios, ETC/DXT(1/5) для android.
• (программистам) Атласы имеют размеры 2^N
• (программистам) Все используемые картинки - квадратные.

Может быть, что-то забыл. Что забыл, напишу позже.

Эффект молнии в Unity3d

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

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

Вот примерно это у меня в конце и получилось: 

Как решить этот вопрос?

Нулевая мысль: надо загуглить. 

В гугле много примеров, советов, много из них полезного, но большинство из них - просто болтовня.

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

Устал искать, решил взять заготовку и написать сам.

Первая мысль: использовать партиклы. 

Как? Непонятно. У кого есть идеи, велком.

Вторая мысль: шейдером.

Сделать в любом редакторе 3d прямую, а потом создавать ее, применив фрагментный шейдер, который будет:

• отрисовывать ее не сразу, а по какому-то времени. Таким образом, мы добьемся эффекта, что молния "бьет", можно управлять скоростью.
• рисовала не прямую, а ломаную в заданной амплитуде. По сути, это просто: амплитуда - это просто абсолютное значение координаты относительно Y, нужно делать кривое зеркало в 1D пространстве.
• ну и цвет - простое умножение на цвет. 

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

Уже решение: взять и тупо рисовать.

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

Более того, в Unity уже есть так называемый trail renderer, в нем есть и толщина линии, и материал с нужным мне цветом. По названию понятно, что это штука, которая рисует на позиции, где побывал гейм-объект. Юнитеки будто знали :) То есть вся задача заключалась в том, чтобы создать пустой трансформ в точке А и довести ее до точки В, в update иногда сбивая ей маршрут.

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

http://93.182.4.16/lightning/lightning.html