Social Gaming с Playtika. Как мы писали одну из крупнейших платформ для слот- машин. Social Gaming с Playtika. Обзор добавлен: 25.08.2015 Последнее обновление: 24.09. Современный дизайн, удобный и понятный интерфейс; Большой выбор игровых бонус Бонус на первый депозит (от 1000RUB) забрать бонус! Как мы писали одну из крупнейших платформ для слот- машин. В продолжении совместного проекта dev. Бонус активе до: Активен до отмены Максимальная сумма к выводу: 5000 RUB. Если вы выбрали слоты для игры - не ждите когда закончится вращение. Бонус в размере 500 рублей за регистрацию без депозита в казино "Джекпот". Слот - машины имеют различное количество барабанов и игровых линий. Playtika Григорий Перепечко, Mobile Client Architect в минском офисе компании, рассказывает о технической стороне создания одного из крупнейших в мире мобильных приложений для социальных слотов. Начало: стакан мобильных движков наполовину отсутствовал. На дворе был 2. 01. Playtika приняла решение о разработке новой мобильной игрушки, разумеется, на слот- тематику. Пока продакт- менеджеры окучивали «джиры», рисовали диаграммы Ганта и творили прочую бесценную бюрократию, мы мучились вопросом «На чём писать?!». Минский офис был только- только сформирован, и готовых технологий для разработки игр мы не имели. Был проверенный десятилетиями C++, компилирующийся под все мыслимые и немыслимые платформы, уйма движков и даже редакторов под него. Была возможность писать нативно, от которой сразу же отказались из- за банальной дороговизны и сложностей с синхронизацией команд. Имелся также модный и современный C#, который Мигель ди Иказа с товарищами из Xamarin отчаянно продвигали как философский камень для мобильной разработки под Android, i. OS и Windows Phone. Мудрые менеджеры взвесили простоту C# на одной руке и зарплаты хороших C++- разработчиков на другой, посмотрели из широкого окна на стены монументально стоящего БГУИР и сделали выбор в сторону более мейнстримового C#. Но игра — хитрая штука, которая тысячи раз в секунду сообщает GPU, что хочет взять шейдер Ш, текстуру Т и отрисовать оными пару сотен треугольников. А также декодирует по чуточку бэкграунд- трек, чтобы ласкать слух игрока, и не повредит обсчитывать пару десятков анимаций, дабы картинка не казалась слишком унылой. И конечно же для всего этого необходим игровой движок. А стакан мобильных игровых движков в 2. Выбрать можно было из Unity, Axiom, Delta. Engine, Mono. Game — пожалуй, и всё. И каждый из них содержал по ложке сочного дёгтя. Изобилующий #ifdef Mono. Game, медленный и не умеющий работать с масками и видео Unity были не лучшим выбором для очень простой, но требовательной к мелочам игры. И как бы невзначай все пришли к неизбежному — нужно писать своё. Свой- то уж точно будет лучше, быстрее, стабильнее, чем все чужие. Так зародился в наших недрах Monosyne, в основу которого лёг архитектурный подход XNA. В команде были и остаются люди, умеющие писать игровые движки, и это отчасти спасло ситуацию, однако никто из бизнеса не понимал, что нужно довести технологию до некой логической завершённости, и таким образом после пары месяцев работы над движком, при полном отсутствии какого- либо инструментария, ещё одна команда начала работать над игрой. Движок только утром научился рисовать текстурированные треугольники, а команда, гонимая Скрамом, уже к обеду хочет класть «чекбокс» на «попап», да ещё и с удобным API. Хочется отметить удачное решение — поддержка десктопной Windows с ранних этапов как третьей платформы наряду с Android и i. OS, что сэкономило километры нервов во время отладки. Xamarin времён 2. Временами «отваливался» отладчик. Сама по себе Xamarin Studio не содержала всех инструментов, к которым мы привыкли. В библиотеке классов BCL были баги и отличия в поведении от имплементации Microsoft. Да и просто заливка сборки на устройство занимала много времени. Поэтому возможность написать и проверить код под Windows в удобной Visual Studio с R#, залить это дело в git и довериться команде тестирования была глотком свежего воздуха. Для бизнес- приложений такой подход видится малореальным из- за сильной зависимости от платформенных UI- контролов, а для игры c 9. Из забавных проблем, с которыми пришлось столкнуться, — отсутствие поддержки Portable Class Libraries в Xamarin. Представьте, вы пишете под три платформы, но вынуждены иметь три копии одного и того же проекта. На тот момент выкрутились генерацией проектов. В шапку проекта без списка файлов оный генерируется и дописывается по некоторым правилам. Таким образом, если вы добавили какой- нибудь класс, для его появления в проектах для других платформ нужно было перезапустить генератор. Звучит жутко. Не кодом единым.. Но не кодом единым жив проект. Ведь чтобы порадовать глаз игрока, нужно что- то показывать и желательно анимировать. Вернёмся к началу проекта. Движку пара месяцев, он может открыть PVR и PNG, есть «арты» от художников в виде PSD и чёткое понимание, что контентно- ориентированные игры так не делаются. Необходим оптимизированный для телефонов формат игровых сцен, с анимациями и прочими радостями геймдева. А главное — нужен способ подготовки этих сцен специально обученными людьми. Тут опытный разработчик вспомнит заветные «тулсет», «редактор сцен», но игру хотят уже вчера, и несколько месяцев на инструментарий никто не даст. Посему появился набор правил, по которым специально обученные ребята называли слои в «фотошопе», и скриптик, который умел разбирать эту PSD в сцену в нашем формате. Назвать это неудобным — ничего не сказать. Поэтому после нескольких месяцев мучений взгляд упал на Adobe Flash и экспорт из его формата, а там — и анимации, и bitmap- маски, и разного рода эффекты. Технология для игр, подобных нашей, оказалась довольно удобной, а главное, что найти специалиста по flash вполне реально. Эволюционировал движок, код и процессы разработки. Хочу рассказать о паре вещей, без которых было бы сложно организовать процесс работы на проекте в 6. Continuous integration Разработчик заливает код в репозиторий, Teamcity запускает билд из его ветки на все платформы. Через 5- 7 минут билды под WP8, i. OS, Android, Win. Причём в них зашивается информация о номере билда, ветке, конфигурации и номере коммита, из которого они собраны. Это экономит время на выяснение деталей. Когда разработчиков стало много, мы отключили автобилды для всего, кроме мастера, но QA могут запускать нужные им билды в один клик. Для того чтобы QA мог поставить билд с устройства, мы написали простенькую страничку на PHP, которая ходит в Teamcity API и получает список билдов. Для i. OS потребовались некоторые приседания с info. WP8 пришлось купить сертификат от Symantec для подписи билдов. Экономия времени — колоссальная. Log Storage. Приложение в процессе работы пишет подробные текстовые логи в файл. И в приложении есть удобная возможность отослать логи в хранилище. Причем отсылается как лог текущей сессии, так и предыдущей, чтобы можно было увидеть краш- лог. Ссылку на лог удобно присоединять к тикету в Jira. Также по всем логам можно организовать поиск, например, чтобы найти редкий паттерн, на который QA иногда наталкиваются, но не сообщают о нём. А главное — QA экономят время на подключение устройства к компьютеру и снятию логов нативным способом (adb, xcode). Кроме того, логи можно отослать в релизе, потапав по скрытой кнопке. Также они автоматически отправляются, когда игрок делает запрос в Customer Support. Так проще разобраться, что же именно у него пошло не так. Git flow/Pull requests Читая reddit, можно внезапно подумать, что сейчас в тренде Trunk- Based Development. Вероятно, так и есть для компаний, где в один репозиторий коммитят сотни разработчиков. Для 1. 0- 1. 5 человек мы пришли к почти классическому Git- Flow. Есть мастер, от него feature- бранчи, от мастера же релизные ветки на пару дней. Для тегов применения не нашлось, а релизные ветки никогда не удаляются. Все ветки «мержатся» исключительно туда, откуда были созданы. Никакие перекрестные merge’ы не разрешены, force push и rebase опубликованных веток запрещён. Pull Request’ы помогают делиться знаниями и работают как экран от явных косяков. Если верить Стиву Макконнеллу, ревью снижает цену исправления ошибок в сто и более раз в случае, если ошибка дошла до юзеров. В нашей команде из 1. PR’ы, а прямые коммиты запрещены (за этим следит Atlassian Bitbucket Server). Для мержа требуется два одобрения от коллег, билд на Teamcity (он информирует Bitbucket о результатах билдов через интеграционный плагин) и одобрение от QA. Есть правило релевантных аппруверов, что означает обязательные аппрувы от людей, хорошо разбирающихся в области изменений. SDDПеред разработкой каждой фичи составляется документ, описывающий общие соображения. Плюсы: разработчики стали больше задумываться над тем, что же они будут писать, как оно будет работать у миллионов юзеров и как в целом одна фича влияет на всё приложение. Здесь присутствует лёгкий аромат бюрократии, но всё- таки это хороший способ уговорить разработчика подумать о том, что он напишет, а не сразу бросаться в объятия IDE. После разработки этот документ остаётся на корпоративной вики, и всегда можно глянуть техническую информацию по каждой фиче. Ниже — контрольный список для составления SDD: Configuration keys (dynamic config, segmentation approach, persistent application settings). Assets (embedded/external, approximate size, lifetime in memory, aspect ratios). Network calls (role, estimated response size, frequency, custom timeout, specific error handling, retry/fallback strategy, websocket application possibility, response caching possibility). Device storage usage (estimated footprint, corruption fallback, cleanup on expiration). Forward compatibility (foresee future changes that should be backward compatible). Logic modularity(excludability) (how easy can the logic be removed/disabled from project, critical for promotional/temp features). Ability to reuse existing common infrastructure (Payments, Remote Resources/Assets, Facebook). Ability to be reused in multiple projects (CS, SM, SR, VDS, WLC). Application performance implications (app loading time, feature loading time, heavy operations in runtime, memory/graphics memory usage, overdraw, draw call count). UML diagrams (sequence with requests/user actions, flow diagram with business logic, incoming/outgoing logical dependencies). Incident monitoring/hotfixing possibilities (event streaming, dynamic config, text logging). Development/Testing helpers (integration with Service popup, Windows hotkeys, hardcoded test data/api stubs).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. Archives
January 2017
Categories |