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