Представим себе что вы захотели написать свою первую игру. Более того, представим что вы захотели написать ее для смартфонов и планшетов. Уже представили или действительно захотели? Что ж, в таком случае рассмотрим трудности с которыми придется столкнуться, на примере моего пути.
Трудность номер один — выбор идеи игры. Сразу отбрасываем варианты супер ММОRPG с блекджеком и корованами, так как в случае успеха, мир будет слишком шокирован произведением ААА шедевра от начинающего геймдевелопера. Так что на выбор остается что-то простенькое, примерно на один-два игровых экрана. Рассмотрим возможных конкурентов — тетрис, 3 в ряд, линии и т.д. весьма популярные игры, несмотря на простоту игрового процесса и программирования. Если задуматься, в них просматривается одинаковая идея — на поле появляются игровые элементы, от которых нужно избавиться. Ну и последние тенденции мобильных игр говорят нам что лучше всего избавляться методом слайда (жеста) по тач экрану (привет Fruit Ninja). Лично так я пришел к мысли о цветном поле с квадратными элементами, ну а чтобы их удалить нужно найти три элемента одного цвета, которые формируют прямоугольник. Всего одно движение по прямой (диагональ прямоугольника) уничтожает все элементы которые в этот прямоугольник попали. Просто? Да. Все как и требовалось по условиям.
Трудность номер два — выбор инструментов с помощью которых можно создать игру. На сегодня нас конечно же интересует кросплатформенная функциональность, чтобы созданное творение могло запускаться на разных платформах (хотя бы Windows, Mac OSX, iOS, Android). Если вы совсем не знаете программирования, можете попробовать свои силы в игровом конструкторе (например GameMaker: Studio), если программирование для вас не чуждо, можете попрактиковаться в более продвинутой среде (например Unity). Ну и если вы совсем уверенный программист, можете использовать более низкоуровневые инструменты. Так как люблю в свободное время программировать на паскале, то выбрал Lazarus+ZenGL. Вполне завершенные продукты, пригодные для игрописания.
Трудность номер три — графика. Лучше всего договориться с хорошим художником или дизайнером. Это действительно лучшее решение, особенно если художник из вас никакой. Если уж собрались сами все делать — постарайтесь не прыгать выше головы и трезво оценивайте свои способности. К счастью, сегодня в моде минимализм (вспоминаем последние дизайны интерфейсов от Microsoft и Apple), так что и в игре можно придерживаться того же принципа. Не забываем что к графике свойственно добавлять озвучку. Желательно качественную. Очень желательно.
Трудность номер четыре — создание интерфейса. Если выбранный инструментарий уже имеет все необходимое — это просто чудесно. В обратном случае придется потратить весьма много времени на разработку кода ответственного за GUI. Особенно это отягощается необходимостью проектировать под разные девайсы с разным dpi, разрешениями и пропорциями экранов. Решений несколько — совсем проигнорировать проблему и писать все под один экран (очень просто в разработке, ужасно в результате). Чтобы как-то сгладить ситуацию, полученное финальное изображение можно масштабировать, чтобы оно нормально поместилось на экран, однако при этом теряются детали и четкость интерфейса (линия в один пиксель может стать размытой на несколько пикселей, ну и вместо попиксельных движений получим скачки через несколько пикселей). Или можно рассчитывать все координаты в условных единицах, например дюймах. Тогда можно гарантировать что нарисованная кнопка будет иметь одинаковый физический размер даже на совсем разных экранах, все необходимые детали будут иметь именно ту четкость, которую ми зададим, ну и останутся попиксельные анимации. Однако это не отменяет того, что контролы могут не помещаться на некоторых экранах, что создает сложности при проектировании интерфейса. Мною был выбран вариант где-то между этими двумя подходами. При разработке выбирается константный проектируемый размер экрана, в координатах которого и происходит добавление всех контролов. Сам GUI движок гарантирует что этот проектируемый размер полностью отобразиться на экране девайса (с помощью предварительного масштабирования). При добавлении контрола указывается позиция (в проектируемых координатах) и якоря (anchors) — желаемое изменение позиции/размера контрола при несоответствии размера реального экрана к проектируемому. По сути эти два параметра (позиция в проектируемом экране + якоря) позволяют движку GUI определить где должен размещаться контрол (уже в реальных пикселях) учитывая разрешение экрана и отличия в пропорциях, хотя при разработке все рассчитывается в фиксированных координатах. Например вот так может выглядеть один и тот же экран при разных разрешениях:
Такой подход относительно простой при проектировании интерфейса и дает хороший результат на разных девайсах. К тому же правильно спроектированный интерфейс сможет нормально работать как в ландшафтном, так и в портретном режиме без использования избыточного дублирующего кода. Исходный код GUI движка что у меня получился можно скачать по ссылке в конце статьи. По правде сказать этот код занял примерно 80% времени от разработки всей игры.
Трудность номер пять — маркетинг. Проще всего попробовать выехать на популярности другой игры. Похожий геймплей, стилистика или даже просто похожее название способно привлечь уже сформировавшийся интерес у игрока. Не зря же последнее время появилось столько игр с словом «angry» вначале названия. Если игра отличается по гейплею от всего остального (как в моем случае) ее уже сложнее пропиарить, тем более что не все игроки при первой игре понимают что нужно делать. Об маркетинге мобильных игр можно почитать хорошую статью на хабре (http://habrahabr.ru/post/147243/).
Трудность номер шесть — отпраздновать выход игры. Ну здесь уже каждый справляется как может, чем может и когда может. Советы давать не буду.
Трудность номер семь — написать статью на хабр.
П.С. Остальные трудности пока находятся в режиме разработки.
Возможно полезные ссылки:
Скачать исходники GUI можно здесь
Опробовать результат в виде игры можно на Google Play
Автор: Corwal
