Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 27
Работа конечно огромная, а игра где?
Ссылки приведены в конце статьи, дублирую.
Очень серьезный подход к разработке, молодцы! Такой же еще и к визуальному оформлению применить бы.
Спасибо за отзыв :)
Может быть есть какие-то конкретные рекомендации по визуальному оформлению? По сути мы сейчас развиваемся методом проб и ошибок, поэтому нам крайне важно получить независимую оценку. Кроме того, данный интерфейс (версии 1.3) уже существенно отличается в лучшую сторону от первоначального (версий 1.0-1.2).
Может быть есть какие-то конкретные рекомендации по визуальному оформлению? По сути мы сейчас развиваемся методом проб и ошибок, поэтому нам крайне важно получить независимую оценку. Кроме того, данный интерфейс (версии 1.3) уже существенно отличается в лучшую сторону от первоначального (версий 1.0-1.2).
Критик из меня так себе, но я попробую перечислить моменты, которые бросились в глаза:
Прошу не принимать мои предложения как критику. Статья все же о пайплайне разработки, а не о графике. Удачи!
- Текстуры заметно тайлятся. Трава на фоне и на поле, где ползает змейка, идёт очень заметными повторяющимися кусками. Не лучше ли было использовать одну текстуру без повторений? Или вот, например, на фоновой картинке таблицы рекордов тоже стоит тайлящаяся картинка, но за счет изменений цветности и «выбеленности» некоторых участков ощущение повторяемости уже не такое сильное. Я понимаю, что вы старались придерживаться мультяшной стилистики, но всё же текстуры можно сделать на основе фотографий, их много на cgtextures, в резделе nature/grass.
- Границы сред никак не обозначены. На стыках фоновой травы и камней можно сделать небольшое затенение, чтобы визуально улучшить разделение этих объектов. У вас так сделано на границах досок. А вот на траве поля его нет, — и сразу кажется, это ковер, расстеленный на камнях. Одинаковых, кстати.
- Элементы управления сливаются с окружением. Тот же эффект тени, отбрасываемой ими на картинку игры, и выделение их другим цветом создадут впечатление того, что они не имеют отношения к миру игры, как камни, например.
- Я бы порекомендовал больше использовать эффекты полупрозрачности. Плавные переходы наше всё :)
- Слишком много «рамочек». Полосатый фон, потом белая рамка, потом фон травы, потом окаймление из камней. Впрочем, это дело вкуса.
Прошу не принимать мои предложения как критику. Статья все же о пайплайне разработки, а не о графике. Удачи!
Unity для 2D змейки мне кажется аналогией «из пушки по воробьям» стрелять. Почему выбор пал именно на Unity? Рассматривали ли вообще другие технологии?
Совершенно согласен и, более того, упоминал об этом в статье. Змейку гораздо проще и быстрее было бы написать на «голом» ADT, но одной из целей было как раз познакомиться с Unity, поэтому выбрали что-то не сложное.
Мы смотрели пару других платформ, но ни одна не заинтересовала так, как Unity.
Мы смотрели пару других платформ, но ни одна не заинтересовала так, как Unity.
Да ладно, Юнити не такой уж сложный движок, в свете того, что в него добавили 2д, еще проще стало.
Unity — это очень удобная пушка. С неё и по воробьям не грех пострелять.
Отличная статья, спасибо. Эх, давно хочу научиться так проектировать приложения, только не знаю, как.
Что касается самой игры, то на экране с разрешением 800*480 интерфейс выглядит очень мелко. Пошаговое движение змейки сильно напрягает. В остальном всё прекрасно.
Что касается самой игры, то на экране с разрешением 800*480 интерфейс выглядит очень мелко. Пошаговое движение змейки сильно напрягает. В остальном всё прекрасно.
Статья хорошая, но очень уж сложная. Мне кажется, в конце можно было бы выделить ключевые моменты проектирования игры на Unity в разрезе особенностей работы с объектами этого же Unity (у вас получилось очень обобщенно). Я тоже начинающий Unity-разработчик и уже успел ощутить, насколько там сложно разделить код на модули. Мы с коллегой-художником тоже решили начать с простых 2D игр для Android, 2 из которых в итоге, как и вы, успешно опубликовали в Google Play. В первом проекте в скриптах творился полный хаос. Второй я начал писать более осмысленно, старался как можно больше инкапсулировать, но все равно связей осталось много, и какие-то выводы сделать достаточно сложно. Заметил, что учитывая простоту, вы все равно решили разбить по сценам. Я же, после первого проекта, наоборот решил, что одной сцены вполне хватит (что позволило, к слову, сделать плавные выезжающие менюшки).
Если бы у меня были простые рецепты, я бы их написал, но, к сожалению, это не так. Предлагаю вместе двигаться в сторону открытия этих рецептов.
Я вижу преимущество в разделении сцен в том, что независимые компоненты максимально разделены, в т.ч., при добавлении различных новых режимов игры (например, кампании), я буду только расширять состав сцен и модифицировать интерфейс меню. Основная же логика останется в неприкосновенности, это должно минимизировать вероятность внесения новых ошибок в отлаженную функциональность.
А выплывающие меню можно сделать путем переиспользования классов, отвечающих за построение меню, например, в моем случае это можно сделать так:
Собственно, я бы сделал именно так, независимо от того, была бы у меня одна сцена или несколько.
Но в любом случае, я инкапсулировал всю логику, связанную со сценами, в один класс GUINavigator, так что в моем случае замена на одну сцену — дело 15 минут, если возникнет такая необходимость.
Я вижу преимущество в разделении сцен в том, что независимые компоненты максимально разделены, в т.ч., при добавлении различных новых режимов игры (например, кампании), я буду только расширять состав сцен и модифицировать интерфейс меню. Основная же логика останется в неприкосновенности, это должно минимизировать вероятность внесения новых ошибок в отлаженную функциональность.
А выплывающие меню можно сделать путем переиспользования классов, отвечающих за построение меню, например, в моем случае это можно сделать так:
- Взять код, отвечающий за построение интерфейса меню (содержимое метода OnGUI) и выделить его в отдельный класс.
- Изменить класс MainGUI (или SettingsGUI — в зависимости от того, какое именно меню хотим выделить), убрав из него отрисовку меню, но пронаследовав от нового созданного класса.
- Пронаследовать GameGUI от нового класса и добавить вызов отрисовки меню + анимацию выезжания
Собственно, я бы сделал именно так, независимо от того, была бы у меня одна сцена или несколько.
Но в любом случае, я инкапсулировал всю логику, связанную со сценами, в один класс GUINavigator, так что в моем случае замена на одну сцену — дело 15 минут, если возникнет такая необходимость.
Много, однако, в вашем сообщении аббревиатур GUI. А я вот в процессе изучения матчасти не раз встречал плохие отзывы об этом компоненте движка. Якобы метод OnGUI слишком тяжеловесный, создает дополнительные DrawCalls, что негативно сказывается на производительности, в особенности на мобильных устройствах. Хотя, поиграв в вашу Змейку, могу сказать, что работает все очень гладко и быстро, видимо продуманная архитектура дает плоды:)
И все таки из-за загрузки новой сцены вы не сделаете красивые переходы. Это ведь как одностраничный и многостраничный сайт. Ну это так, на вкус и цвет. Мне просто понравились мои переходы (можете заценить)
Еще немножко оценю вашу игру, если вы не против. Текст на кнопках очень мелкий, вы не отталкиваетесь от размера экрана при их инициализации? Рекламу сделали, а вот онлайн таблицу рекордов нет. Посчитали ненужным или не захотели перегружать игру излишним функционалом?
И все таки из-за загрузки новой сцены вы не сделаете красивые переходы. Это ведь как одностраничный и многостраничный сайт. Ну это так, на вкус и цвет. Мне просто понравились мои переходы (можете заценить)
Еще немножко оценю вашу игру, если вы не против. Текст на кнопках очень мелкий, вы не отталкиваетесь от размера экрана при их инициализации? Рекламу сделали, а вот онлайн таблицу рекордов нет. Посчитали ненужным или не захотели перегружать игру излишним функционалом?
И все таки из-за загрузки новой сцены вы не сделаете красивые переходы.
Не будьте так категоричны. В своей первой игре (Fondemzel Labyrinth) я использовал плавные переходы между сценами таким образом: перед выгрузкой сцены экран затеняется в ноль, а при загрузке другой — постепенно высветляется до нормального состояния из кромешной черноты. Думаю, таких примеров можно привести множество.
Использование нескольких сцен — одна из возможностей распределения игровых ресурсов и их сортировки, причем очень мощная и удобная.
Вы правы в том, что к разработке OnGUI необходимо подходить очень тщательно, чтобы не было проблем с производительностью. Об этом пишут в т.ч. сами разработчики Unity, и уже вышла бета-версия с новым механизмом UI, который должен заменить устаревший OnGUI. Вы, кстати, ее уже попробовали? На чем делали свой интерфейс?
Однако, вы ошибаетесь в том, что раздельные сцены не позволят сделать красивые переходы: это вещи совершенно не связанные.
Возможно, раздельные сцены не позволят сделать переходы так, как они сделаны у вас, но это совсем другая формулировка, верно?
Разделение на сцены объективно имеет как преимущества, так и недостатки. Но субъективную оценку красоты предлагаю оставить игрокам, все-таки, это им должно нравится приложение, а не нам с вами.
Вам правда интересно про таблицу рекордов? Просто в вашей фразе
оба варианта суть одно и то же. Обычно так говорят, когда для себя уже все решили, что печально. Если все же интересно, то онлайн таблицу рекордов мы планируем сделать одновременно с дополнительным режимом игры — прохождением кампании.
Однако, вы ошибаетесь в том, что раздельные сцены не позволят сделать красивые переходы: это вещи совершенно не связанные.
Возможно, раздельные сцены не позволят сделать переходы так, как они сделаны у вас, но это совсем другая формулировка, верно?
Разделение на сцены объективно имеет как преимущества, так и недостатки. Но субъективную оценку красоты предлагаю оставить игрокам, все-таки, это им должно нравится приложение, а не нам с вами.
Вам правда интересно про таблицу рекордов? Просто в вашей фразе
Посчитали ненужным или не захотели перегружать игру излишним функционалом?
оба варианта суть одно и то же. Обычно так говорят, когда для себя уже все решили, что печально. Если все же интересно, то онлайн таблицу рекордов мы планируем сделать одновременно с дополнительным режимом игры — прохождением кампании.
Насчет новой системы пока не слышал. Но нынешняя настолько неудобна, что интерфейс делали на спрайтах. Там, где требовался вывод какой-то динамичной информации, я добавлял объекту компонент GUIText, в редакторе настраивал местоположение и в коде при надобности менял ему текст. То есть метод OnGUI я не использовал. Но как это работает внутри, неизвестно. Возможно, компонент GUIText подразумевает, что текст все равно рисуется каждый кадр, возможно — нет.
На сайте юнити есть хороший и простой урок по плавным переходам между сценами unity3d.com/ru/learn/tutorials/projects/stealth/screen-fader
Не добавляйте управление гироскопом! Я читал несколько статей, где это критикуют. Сам играл в гоночную игру с управлением гироскопом — всего лишь надо влево-вправо поворачивать телефон, чтобы мотоцикл ездил влево-вправо, но было жуууутко неудобно.
Добавлю, что 2d режим в юнити ещё сыроват. Я делал небольшой проект, где-то с десятком анимаций и сотней статичных спрайтов. Через некоторое время стало крашиться где-то в недрах движка на загрузке анимаций. Воспроизводилась эта бага месяц назад точно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Архитектура простой 2D игры на Unity3D. План, факт и работа над ошибками