С августа в свое свободное время я занимаюсь разработкой занятной risk-подобной игрушки, в мире известной под названием Dice Wars. Гениальный японский гейм-дизайнер Таро Ито придумал замечательные правила этой игры и создал ее на флеше (однопользовательскую), и она породил множество вариаций на эту тему, до сих пор плохо известных в России.
В этой статье я хотел бы проанализировать мой первый fail с risk-подобной игрой, о которой я писал в марте, рассказать, почему я отказался от идеи использовать App Engine везде и вся, показать связку из App Engine + Twisted к которой я пришел и которая, как мне кажется, довольно полезна для приложений с постоянным соединением. Кроме того, хотелось бы рассказать о своем опыте с Actionscript 3, что-то вроде взгляда back end разработчика на эту чуждую для меня технологию, а также поискать здесь на хабре компаньонов и единомышленников.
Этой зимой мне пришла идея использовать App Engine в качестве сервера приложения, реализующего polling патерн для мгновенного получения событий с сервера. Т.е. это такое приложение, которое посылает запрос на сервер раз в секунду и получает действия других пользователей, сообщения чата и так далее. В качестве примера я решил сделать простенькую risk-стратегию и использовать в ней карты от Google, их JavaScript API. И в этой игре я допустил две ключевые ошибки, на мой взгляд такие.
Во-первых, при всех прелестях JavaScript в данный момент он не может заменить Flash/Silverlight, а многие вещи сложно реализуемые. Прогрессивные браузеры конечно поддерживают много хороших фишек, но как и 10 лет назад приходится делать if'ы/switch'и для совместимости с другими браузерами. Кроме того, совмещение например canvas и карт Google затруднительно. Это делает сложным создание различных рюшечек, так необходимых в играх.
Во-вторых, использовать polling оказалось плохой идей, и не из-за того что это создает сильную нагрузку на App Engine, с этим он справится, а из-за того что polling сложен в разработке.
С тех пор появился Channel API, но он по прежнему не дает той гибкости, которую вы имеете при разработке своего сервера, поддерживающего постоянное соединение. Одно дело, когда все объекты у вас подгружены внутри программы, вы свободно ими оперируете и по своей логике распределяете нагрузку между серверами, и другое дело, когда вы не можете быть уверены на какой сервер пришел запрос и вам нужно каждый раз запрашивать все объекты заново, не нужные объекты не запрашивать и заботится о кеше в memcache. Я надеюсь в будущем Google введет более удобную и гибкую работу с экземпляром (inctance) приложения.
Я делал несколько подходов в изучению Flash, пробовал читать книжки, открывал Flash IDE и каждый раз я испытывал какой-то необъяснимое отторжение ко всем этим кнопочкам, окошечкам, помощникам. Flash IDE довольно не похож на такие среды как Eclipse или Visual Studio и требует тщательного изучения. Решение оказалось простым. Есть Flex SDK, компилятор mxmlc и с ними разработка оказывается традиционной. Для VIM существует плагин, а Actionscript 3 приятный современный объектно-ориентированный язык программирования. Если вы испытываете подобные проблемы, то возможно вам стоит попробовать такой путь.
Схема, к которой я сейчас пришел, изображена на рисунке. Игровая механика перенесена на отдельный Linux сервер, на котором запущен демон, принимающий постоянные соединения от клиентов. Для создания постоянного соединения на клиенте используется Flash, а при нехватки мощности Linux сервера, игра довольно просто масштабируется. Это не универсальное решение на все случаи жизни и оно предполагает, что вы можете разделить игровые объекты по разным серверам. В моем случае игры происходят в разных «комнатах» и эти комнаты могут находится на разных серверах, все что внутри комнаты свободно помещается на одном сервере.
Если же вы бы делали супер глобальную игру, в которой в одной локации бы играли сто пятьсот тысяч миллионов человек, которые бы динамично взаимодействовали между собой, то скорее всего Channel API вам сумел бы предложить более гибкий подход в этом случае.
App Engine в моей схеме стал центральным сервером аутентификации и сервером статистики. Когда клиент соединяется с Twisted, для аутентификации Twisted делает запрос к App Engine и проверяет тот ли это клиент, за кого себя выдает. Статистика же это просто прекрасная область для применения App Engine.
Для различной аутентификации я написал библиотечку, диаграмма классов которой изображена на рисунке. End User (конечный пользователь) приложения наследуются от User библиотеки, которая в свою очередь связана через композицию с различными схемами аутентификации.
Все это происходит на сервере App Engine и для Twisted сервера не имеет значения откуда пришел клиент.
В настоящее время я испытываю проблемы с дизайном и с раскруткой (маркетингом). Если вы разбираетесь в чем-то из этого, у вас есть свободное время, желание что-то делать, но вы не знаете к кому примкнуть, я был бы рад разделить прелести творческого процесса с вами, просто напишите мне личное сообщение или email. Желание найти профессионалов своего дела, возможность когда-нибудь создать сильную команду разработчиков, были одними из целей, ради которых я написал эту статью.
Сайт игры В Кубики
Приложение на Facebook
Приложение В Контакте
Приложение в Моем Мире
В этой статье я хотел бы проанализировать мой первый fail с risk-подобной игрой, о которой я писал в марте, рассказать, почему я отказался от идеи использовать App Engine везде и вся, показать связку из App Engine + Twisted к которой я пришел и которая, как мне кажется, довольно полезна для приложений с постоянным соединением. Кроме того, хотелось бы рассказать о своем опыте с Actionscript 3, что-то вроде взгляда back end разработчика на эту чуждую для меня технологию, а также поискать здесь на хабре компаньонов и единомышленников.
Первый блин
Этой зимой мне пришла идея использовать App Engine в качестве сервера приложения, реализующего polling патерн для мгновенного получения событий с сервера. Т.е. это такое приложение, которое посылает запрос на сервер раз в секунду и получает действия других пользователей, сообщения чата и так далее. В качестве примера я решил сделать простенькую risk-стратегию и использовать в ней карты от Google, их JavaScript API. И в этой игре я допустил две ключевые ошибки, на мой взгляд такие.
Во-первых, при всех прелестях JavaScript в данный момент он не может заменить Flash/Silverlight, а многие вещи сложно реализуемые. Прогрессивные браузеры конечно поддерживают много хороших фишек, но как и 10 лет назад приходится делать if'ы/switch'и для совместимости с другими браузерами. Кроме того, совмещение например canvas и карт Google затруднительно. Это делает сложным создание различных рюшечек, так необходимых в играх.
Во-вторых, использовать polling оказалось плохой идей, и не из-за того что это создает сильную нагрузку на App Engine, с этим он справится, а из-за того что polling сложен в разработке.
С тех пор появился Channel API, но он по прежнему не дает той гибкости, которую вы имеете при разработке своего сервера, поддерживающего постоянное соединение. Одно дело, когда все объекты у вас подгружены внутри программы, вы свободно ими оперируете и по своей логике распределяете нагрузку между серверами, и другое дело, когда вы не можете быть уверены на какой сервер пришел запрос и вам нужно каждый раз запрашивать все объекты заново, не нужные объекты не запрашивать и заботится о кеше в memcache. Я надеюсь в будущем Google введет более удобную и гибкую работу с экземпляром (inctance) приложения.
Actionscript 3 для любителей VIM
Я делал несколько подходов в изучению Flash, пробовал читать книжки, открывал Flash IDE и каждый раз я испытывал какой-то необъяснимое отторжение ко всем этим кнопочкам, окошечкам, помощникам. Flash IDE довольно не похож на такие среды как Eclipse или Visual Studio и требует тщательного изучения. Решение оказалось простым. Есть Flex SDK, компилятор mxmlc и с ними разработка оказывается традиционной. Для VIM существует плагин, а Actionscript 3 приятный современный объектно-ориентированный язык программирования. Если вы испытываете подобные проблемы, то возможно вам стоит попробовать такой путь.
App Engine + Twisted
Схема, к которой я сейчас пришел, изображена на рисунке. Игровая механика перенесена на отдельный Linux сервер, на котором запущен демон, принимающий постоянные соединения от клиентов. Для создания постоянного соединения на клиенте используется Flash, а при нехватки мощности Linux сервера, игра довольно просто масштабируется. Это не универсальное решение на все случаи жизни и оно предполагает, что вы можете разделить игровые объекты по разным серверам. В моем случае игры происходят в разных «комнатах» и эти комнаты могут находится на разных серверах, все что внутри комнаты свободно помещается на одном сервере.
Если же вы бы делали супер глобальную игру, в которой в одной локации бы играли сто пятьсот тысяч миллионов человек, которые бы динамично взаимодействовали между собой, то скорее всего Channel API вам сумел бы предложить более гибкий подход в этом случае.
App Engine в моей схеме стал центральным сервером аутентификации и сервером статистики. Когда клиент соединяется с Twisted, для аутентификации Twisted делает запрос к App Engine и проверяет тот ли это клиент, за кого себя выдает. Статистика же это просто прекрасная область для применения App Engine.
Библиотека аутентификации
Для различной аутентификации я написал библиотечку, диаграмма классов которой изображена на рисунке. End User (конечный пользователь) приложения наследуются от User библиотеки, которая в свою очередь связана через композицию с различными схемами аутентификации.
Все это происходит на сервере App Engine и для Twisted сервера не имеет значения откуда пришел клиент.
Ищу компаньонов
В настоящее время я испытываю проблемы с дизайном и с раскруткой (маркетингом). Если вы разбираетесь в чем-то из этого, у вас есть свободное время, желание что-то делать, но вы не знаете к кому примкнуть, я был бы рад разделить прелести творческого процесса с вами, просто напишите мне личное сообщение или email. Желание найти профессионалов своего дела, возможность когда-нибудь создать сильную команду разработчиков, были одними из целей, ради которых я написал эту статью.
Ссылки
Сайт игры В Кубики
Приложение на Facebook
Приложение В Контакте
Приложение в Моем Мире
