Верю – не верю в инди-разработку. Часть 1

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

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

От идеи к реализации

Для начала необходима идея и требования к конечной игре. Разумеется, сразу же, захотелось сделать пошаговую 3D стратегию с элементами RPG класса AAA+ с лазерами и эльфами. Но нужно учитывать тот момент, что фантазия ограничивается возможностями, а значит требования нужно подогнать под эти возможности. С программированием проблем нет и опыт написания сетевых приложений имеется, а это говорит о том, что игра должна быть мультиплеерная. Но так как из художеств я владею только дзеном наложения теней в фотошопе, то графики в игре должно быть минимум.

Пришлось серьезно задуматься над жанром будущей игры. Стрелялки, стратегии и гонки требуют красивой графики, значит разработка одного из таких жанров в какой-то момент упрется в невозможность реализации. А вот карточные игры – соответствуют всем требованиям. Но тут другая проблема – карточных игр настолько много, что заходить туда нужно только с оригинальной игрой. Разумеется «покер» и «дурак» отпадают сразу. Пришлось составлять список возможных карточных игр и проводить опрос среди знакомых, который показал, что многие знают игру «Верю – не верю». И что не могло ни порадовать — толковых реализаций такой игры не было ни на маркетах, ни в соц. сетях!
Решение принято.

Пробежавшись по симпатичным карточным играм гигантам – для внешнего вида игры были сформулированы следующие требования:

• Должен быть карточный стол как в казино;
• Рубашка карт должна быть привычная глазу и «дорогая»;
• Масти карт и их достоинства должны быть легко узнаваемыми;
• Противники должны иметь аватарки и имена, дабы быть уникальными и ощущение игры с живым человеком не терялось;
• Должны быть ежедневные начисления бонусов, чтобы проигравшиеся возвращались;
• Должны быть привлекательные девушки с большими сись

Карты, столы, кнопки и буквы создать получилось самостоятельными силами, а вот с девушками что-то нужно было делать. И за это больше спасибо знакомой художнице – нарисовала требуемое за спасибо (Спасибо Аня!). Правда ближе к публикации пришлось самостоятельно убирать немного кричащей эротики, и замазывать слишком уж откровенные места. (Подробнее в следующей статье).

Вывод 1: Нужно рассчитывать на свои возможности, тогда не наступит момента, когда вам что-то нужно, а вы этого получить не можете (Например 3д модель персонажей для MMORPGMEGA AAA+). Когда вы манипулируете возможностями и желаниями – вы не стоите на месте

Концепт стилистики игры

Let’s cake make

Первое что необходимо для многопользовательской игры – это серверная часть. Что бы все было максимально честно — серверная часть должна обрабатывать все возможные действия пользователей, отсеивать неверные комбинации и всякие «чит-ходы». Иными словами – логика должна быть на сервере а не у клиента.

Разберем составляющие серверной части:
В любой игре должны быть постоянно хранимые данные. Это данные, которые сохраняются для клиента между сеансами. К таким данным относится, например, количество фишек игрока. Вообще хранимых данных оказалось не так уж и много, поэтому участь хранения и обработки таких данных взял(а) на себя MySQL.

Дальше – обработка действий клиента и связь нескольких участников в одну игру. Этим занимается сокет-сервер.

Наиболее доступным языком для сокет-сервера оказалась Java. И раз уж дело встало за написанием сокет-сервера, то решено было сделать API для сервера. Получилось вполне неплохо. На удивление, для полноценной работы игры, понадобилось всего 8 api. Т.е. написание сокет-сервера оказалось гораздо проще, чем казалось с самого начала.

Вывод 2: Не стоит бояться сложностей. Все гораздо проще, чем может показаться на первый взгляд.

Выбираем платформу для клиента

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

ActionScript (Web)
Плюсы: Очень легко работать с графикой. Довольно легкий язык. Кроссплатформенность. Возможность интегрирования в соц.сети с целью привлечения дополнительной аудитории.
Минусы: Никаких мобильных устройств, да и Flash’ом, по моим наблюдениям люди пользуются все меньше.

HTML + JavaScript (Web)
Плюсы: Очень легко работать с графикой. Довольно легкий язык. Кроссплатформенность. Возможность интегрирования в соц.сети с целью привлечения дополнительной аудитоии.
Минусы: Беда (ИМХО) с работой на мобильных устройствах средней ценовой категории. Сокет-сервер необходимо привязывать к стандартам протокола RFC 6455 (а значит увеличить порог вхождения для других языков программирования)

Unity (огромное количество платформ)
Плюсы: Полная кроссплатформенность. Возможность интегрирования в соц.сети с целью привлечения дополнительной аудитоии.
Минусы: Несмотря на то, что игра планируется полностью в 2d формате – придется привыкать что работаешь с 3D. Высокий порог вхождения.

Java (Android)
Плюсы: Довольно легкий язык. Большое количество целевых устройств.
Минусы: Охват только одной платформы.

Swift (iOS)
Плюсы: «Престижная платформа». Бо́льшее количество платящей аудитории в сравнении с другими мобильными платформами.
Минусы: Отсутствие девайсов, на которых можно было бы тестировать разработку

Немного поразмыслив над списком — выбирам Android, как наиболе оптимальный по возможностям и желаниям.

Вывод 3: Необходимо оставлять пути для маневра. Кто знает – если ваш проект взлетит – вы всегда сможете дополнить его новой платформой. Если у вас не складывается с одной платформой – можно перейти на другую.

О создании клиента

Самым оптимальным вариантом для написания каких-либо игр для Android – это использование OpenGL, что является довольно трудоемким процессом и требует отдельных знаний. Поэтому стоит обратить внимание на движки, которые существенно облегчат работу. Мой выбор пал на AndEngine, что в итоге показало неплохие результаты. Единственное что доставило некоторую проблему, так это правильное позиционирование камеры под разные разрешения экранов. Писать обработку координат под разные форматы совсем не хотелось, а оставлять пустые рамки – все-равно что нагадить в клумбу. Пришлось повозиться с форматом камеры которая бы позволяла заполнить весь экран изображением, при этом обрезая излишки и не растягивая содержимое. Получилось довольно неплохо, и вполне симпатично на всех форматах устройств. Описывать работу с AndEngine в данной статье не предполагается, так как тема неоднократно упоминалась на хабре.
Осталось лишь подогнать изображения написать немного кода. Так, спустя совсем короткое время удалось поиграть в собственное произведение, услышать отзывы о проделанной работе с тестирующими.
Вывод 4: Правильное сочетание возможностей и желаний приводит к скорейшему результату.

Скриншот первой, настоящей партии игры

Total:

Обозрев проделанную работу – можно утверждать, что разработка Инди-игры может обойтись вам в приятно проведенное время, при этом абсолютно бесплатно в финансовом плане (Создание, не публикация). Цель статьи в достижении понимания – насколько трудоемким является процесс создания игры и способен ли программист только лишь с навыками программирования создать что-либо играбельное. А так, как что-то играбельное программист может, то верить в инди-разработку все-таки стоит. Но отчасти. Потому как результаты должны приносить плоды. О том принесет ли какую-либо выгоду данное увлечение, как прошла публикация, и на что все-таки придется потратить деньги, решено перенести в следующую статью, так как просто создание игры – это лишь вершина айсберга. И лишь попытавшись получить прибыль с игры, силами одного программиста – можно понять – стоит ли верить в инди-разработку.

ссылка на оригинал статьи http://habrahabr.ru/post/272215/