Как создать игру без знания программирования
Как быть, когда у тебя нет опыта в мобильной подготовке и самые низкие знания языков программирования, однако крайне хочется включить собственную игру, поскольку думаешь ее любопытной и необыкновенной? Пытаться, заблуждаться и идти к задачи далее.
Я поведаю данную историю подготовки с позиции геймдизайнера, контент-мейкера, маркетолога и всех других ролей, помимо прямо сочинения кода и отрисовки внешнего вида.
Мне и моим приятелям нравятся игры, которые способны возбуждать любой неинтересный день в компании. Такие игры должны быть не только лишь забавными, но также и предоставлять игрокам вероятность некоторым стилем вести взаимодействие вместе.
У нас возникла мысль инженеры для викторины, которая находилась на плоскости, однако до нас ее в AppStore никто не воплотил. Да, в супермаркете дополнений полным-полно викторин, однако ни одна не содействует соединению людей и образованию крепкой дружественной окружающей среды. Мы же задались мишенью создать игру, в которую бы желалось играть как в компании, так и состязаться со невольными конкурентами .
Что нас различает:
Аэромеханика. На любой вопрос рекомендуется несколько видов решения, однако верный лишь 1. В самом начале раунда игроку рекомендуется ввести собственный «обман». Как раз из этих подлогов, которые выдумал ты и твои конкуренты, и состоит перечень представленных видов решений. Если конкурент делает ошибки и предпочитает один из подлогов, то игрок, который его выдумал, приобретает особые очки.
Игра сконструирована так, что за подлоги у тебя есть возможность получить больше очков, чем просто разгадывая верные решения. Однако это далеко не один катализатор выдумывать «красивую ложь», так как в ходе игры ты принимаешь подлинное наслаждение от осознания того, что ты «развел» собственного конкурента. Такая элементарная, изначально, аэромеханика дополняет взаимодействия между игроками, поскольку это целиком зависит лишь от твоей советы и находчивости.
Юмор. Для себя мы отделяем 2 вида тем: забавные и на проверку познаний. Забавные — это вопросы, которые выполнены подчеркнуто забавными, как правило о каких-нибудь неизвестных интересных прецедентах («Знали ли вы о подобном прекрасном виде спорта как необычная глажка?»), или выдержки с упущенным словом («_____ фотошопом не подправишь — Джоан Роулинг. Противную натуру? Неимение дара?»).
Такие вопросы открывают большой простор для того, чтобы показать собственное чувство юмора в «обманных ответах», так как нередко верный ответ так внезапный и безмозглый, что и разработать такое было бы трудно. Вопросы на проверку познаний — это нормальные для викторин вопросы, которые рассматривают точную область познаний и увеличивают «чувство своей важности» специалистов.
Максимально точные темы. В существующих играх-викторинах деление на темы происходит чересчур обобщенно, к примеру, «Кино» как правило содержит совместные вопросы о кинематографе, о биографии артистов, о кинофильмах всех годов и жанров и тому подобное. Мы же фокусируемся на точных темах: «Супергеройское кино», «Звездные войны», «Мультфильмы», «Кино в цитатах» и прочих.
Число игроков. У нас в любой игре принимают участие до 4-х игроков, и игра проходит одновременно для всех. Никаких долгих ожиданий решений, лишь стремительные игры, где обнаруживаешь чемпиона. Это также комфортно для оперативных сессий, когда нужно провести 5 секунд в предвкушении кофе либо автобуса. Игровой портал и все о нем смотрите на сайте game-ss.ru.
Так как, как я заявлял, опыта в мобильной подготовке мы не имели, абсолютное большинство познаний понадобилось заимствовать из профильных веб-сайтов, или поверить интуиции. С начала мы планировали все делать целиком вместе, другими словами, принимать все решения многими голосов — демократия и общая свобода слова. В этой связи первый совет:
Если вы делаете дополнение либо игру командой, то в ней в обязательном порядке должен быть основной — он принимает обязанность за установление решений, и его голос главный.
Даже если первоначально у вас одинаковое виденье проекта, ваши соображения когда-то в обязательном порядке разведутся, а решение разногласий займет уйму времени. Так мы истратили 2 месяца, поскольку наши голоса поделились поровну и взять «демократичное» решение было нельзя. В конечном итоге, я получил на себя всю работу по подготовке, как самый бешеный приверженец реализации нашей мысли.
В подготовке есть суждение MVP — Minimum Viable Product (Максимально жизнестойкий продукт). Жалко, что на раунде создания техзадания мы о нем не могли знать. Первоначально мы рассчитывали употребить максимум ресурсов и исследовать, будет ли наш проект любопытен пользователям, нужно ли его развивать.
В 1-м релизе оставьте исключительно те функции, которые нужны для достижения той одной задачи, которую осуществляет дополнение.
Позже мы осознали: это принципиально не только лишь для минимизации затрат, но также и для упрощения дополнения так, чтобы оно было предельно ясно всем возможным пользователям. На 1-м раунде необходимо показать клиенту «душу» дополнения — ее главную мысль, а далее дополнять функции и расти. Пока клиент не убежден в том, что ему любопытно дополнение, не следует проваливать его кучей настроек — это только оттолкнет его.
Вспомните историю формирования Instagram: первоначально он притягивал клиентов собственной простотой, а сегодня мы с превеликим удовольствием разбираемся в десятках его свежих функций.
Содержание консультанта. Роль консультанта не следует преуменьшать, поскольку он отвечает за действенную коммуникацию всех членов команды. Кроме этого, консультант знает нюансы и подводные камни подготовки, предоставляет путные, сформированные на эксперименте, рекомендации. В целом, мы опасались переплатить за собственные ошибки из-за неопытности, плюс это давало мне вероятность больше времени предоставить тексту игры, который мы выполняем сами, и посмотреть и поучиться работе консультанта.
Доверие. Компании больше дорожат собственным искренним названием, потому что когда-нибудь «прославившись» собственной недобросовестностью на рынке, организация может потерять возможных клиентов. Фрилансер же «птица вольная» и изучить его историю труднее.
Направился бы я в настоящее время в студию? Практически невозможно, поскольку в настоящее время я ощущаю себя более уверенно, так как я обрел опыт: обучился говорить и в точности определять цели; узнал, как работают те либо другие сервисы; взглянул, как происходит контроль за работой и как организована коммуникация в команде. И более того, после первого релиза я зашел на работу с фрилансером.
В масштабах подготовки, быстро для себя, я начал целиком контролировать весь процесс создания игры и разговаривать прямо с разработчиком программного обеспечения, обращаясь к помощи консультанта лишь тогда, когда мы совершенно не осознавали друг дружку.
Не страшитесь задавать все вопросы создателю. Это ваш проект и даже если вдруг вы не видите код, логику вам необходимо осознавать в обязательном порядке.
Раздельно стоит отметить значимость объяснений в коде. Это позволит вам, даже с максимальными познаниями языков программирования, разобраться в нем и облегчит переход к другому создателю при необходимости.
2-й половиной работы стало образование текста, а конкретнее сочинение вопросов и тем. Это занимает значительно больше времени, чем может показаться, так как в нашем случае необходимо взвесить не только лишь вопрос и 4 вида решения, но также и все вероятные виды сочинения верного (чтобы игрок, даже если пожелал, не сумел ввести в поле «лжи» верный ответ), и напечатать резервные неправильные виды решений (для тех, кто не желает без помощи других выдумывать «ложь»). Еще некоторое время у меня отобрала адаптация звуков, которые я принимал из свободных библиотек freesound.org и diforb.com.
При подготовке игры исследуете движки, осмыслите преимущества и недостатки любого. Осмыслите, что для вас не менее принципиально, а чем вы способны поступиться.
Невзирая на то, что наша игра не требует физики либо 3D-моделей, выбор пал на Unity. Да, мы осознавали, что врожденная подготовка лучше и легче (в особенности что же касается iOS). Однако основным доводом в пользу выбора многогранного двигателя стала стоимость.
Так как мы давали всю работу на аутсорс, а его плату выпускали из собственных скоплений, то нам было принципиально предельно уменьшить затраты. Билд Unity без проблем выносится на иные программы, а мы, на день начала подготовки, планировали после полновесного релиза на iOS сделать шлюз на Андроид (и до сих пор намереваемся этим заняться).
Верный ли мы сделали выбор? Трудно сообщить на сегодняшний день. В длительной возможности лучше всего, разумеется, делать врожденную подготовку. В случае если вы желаете исследовать, необходим ли ваш продукт рынку, как это было нужно нам, то выбирайте то, что вам ближе и легче: от известного языка подготовки до элементарного чат-бота.
Серверной частью мы избрали не распространенный в РФ, однако довольно знаменитый пасмурный сервис Gamesparks. По версии нашего создателя, платформа крайне комфортная, а мы заметили хорошее соответствие стоимость/качество. Для инди-разработчиков они могут предложить бесплатное техобслуживание до того времени, пока ваш MAU меньше 100 миллионов клиентов.
Что же касается графики и внешнего вида, то после релиза мы осознали, что наш внешний вид не адаптационный и, по какой-нибудь причине, не ложится даже под iPod (действует лишь в режиме х2). На это также советуем обратить свое внимание при подготовке вашего внешнего вида.