New Zombotron 3. Неделя #3

С момента последней записи прошло уже намного больше времени, чем неделя. За это время много всего случилось, но показать и рассказать мне было нечего, поэтому получилась такая пауза.

Не смотря на то, что я запланировал работу с графикой и надеялся получить уже какой-то набор для создания первого уровня, все пошло опять не так, как я ожидал, и виной таким неожиданностям, конечно же, новая технология, с которой я мало знаком.

Забегая вперед, скажу сразу, что создание графики для игры с аппаратной поддержкой — это чуть более сложная задача, чем рисование графики для обычной Flash игры. Вся суть тут кроется в том, что графика для Flash игры выглядит точно так же, как я рисую её в редакторе. А вот с Unity история немного другая и причиной тому динамическое освещение. Динамическое освещение существенно сказывается на том, как будет выглядеть окружение в игре. А когда еще опыта и понимания с этим нет, то приходится регулярно подсовывать объекты в Unity и проверять, как это будет смотреться. Такой подход не очень производительный, но на первых порах без него никак не обойтись, пока я не «набью руку».

Организация графических ресурсов

На первых этапах разработки самая ответственная задача — это подход к правильной организации и оптимизации игровых ресурсов. Это тот самый момент, на который тоже уходит много времени, особенно если заранее не знать, как хорошо и правильно организовать ресурсы в новом движке — приходится искать информацию и экспериментировать. Копаясь с ресурсами, не получаешь никакого визуального прогресса, кроме удовлетворения от того, что «на моих полочках все в порядке». Но по факту правильный подход к организации — это большой вклад в будущее проекта, это фактически, как фундамент для большого многоэтажного дома.

Изначально для каждого объекта я создавал отдельный атлас, отдельный материал, и успешно собирал из этого игровые объекты.

Такой подход хорошо работает ровно до тех пор, пока в игре меньше двух десятков объектов, но чем дальше в горы, тем больше снежный ком. Мало того, что таким образом просто не удобно хранить ресурсы и настраивать материалы для объектов, так еще и страдает производительность из-за невозможности использования батчинга. В общем, тут необходимо сразу озаботиться оптимизацией и организацией графических ресурсов. А именно: упаковкой спрайтов в атласы.

Особенности упаковки атласов

С тех времен когда я работал с 3D и аппаратным ускорением — прошло много времени (с 2008 года) и сейчас многое уже поменялось. Одним из особых нововведений в плане оптимизации, которое меня застало врасплох — это рендер 2D спрайтов.

Как мы все (наверное) знаем, в аппаратном рендере вся графика рисуется через треугольники и полигоны, даже обычное 2D. То есть, чтобы нарисовать обычный квадратный или прямоугольный 2D спрайт — нам нужно два треугольника, которые сформируют полигон, и натянув на этот полигон текстуру (спрайт) мы получим на экране обычную 2D картинку. Естественно, чем меньше треугольников, тем быстрее будет рисоваться наша сцена.

Ранее, когда я работал с 3D — я в принципе знал о том, что текстуры с альфа каналами намного дороже рисовать, чем текстуры без альфа канала, так как для отрисовки прозрачных областей, GPU делает дополнительные перерасчеты для учета прозрачностей и порядка вывода текстур (z-buffer). Но тут я не буду вдаваться в технические подробности и просто скажу, что в целом для 3D это не критично, так как в 3D графике текстуры с альфа каналом используются не часто, и основной фокус ставился конечно же на количество треугольников.

Но время шло, видеокарты на стационарных компьютерах становились мощнее и могли рисовать все больше и больше треугольников, за счет чего и графика становилась все более детализированной и реалистичной. А потом появились мобильные платформы: телефоны и планшеты, а в месте с ними и новая эра игр. И вот, если на стационарном компьютере любая видеокарта уже легко справлялась с прозрачностью для всех текстур в 2D графике, и мы могли делать сколько угодно спрайтов из двух треугольников, не переживая за то, что на стационарной машине из-за этого мы потеряем производительность. То для мобильных устройств все сложнее, GPU там еще не такие быстрые и мощные, и текстуры с прозрачными пикселями — это большая проблема, особенно если мы говорим о 2D играх, так как именно в таких играх альфа канал есть практически в каждом спрайте. Что же с этим делать?

Собственно, выход достаточно простой: отсекать все лишние прозрачные пиксели. Но для этого необходимо создавать для каждого 2D спрайта свой уникальный полигон, соответствующей видимой форме спрайта.

Все, что на картинке обведено линиями — это грани треугольников, таким образом все, что попадает в треугольники, будет отрисовано, а все что не обведено треугольниками, будет проигнорировано. И так мы видим, что некоторая часть прозрачных пикселей успешно отсечена. В рамках одного спрайта это вроде и не так много, но в целом это хорошая оптимизация, если учитывать тот факт, что в 2D играх практически все спрайты имеют прозрачные области. Только вот вопрос: зачем мне эта оптимизация?! Ведь, как я заявлял ранее, игра в первую очередь разрабатывается для PC.

К сожалению или к счастью, в Unity подобная оптимизация встроена, что называется «из коробки» и добавляя любой спрайт в проект, Unity его автоматически разрезает на треугольники. Что-ж очень приятна такая забота. Только вот делает Unity это не очень красиво, и беда тут заключается в том, что создается очень много треугольников, и какой-нибудь незамысловатый спрайт с таким подходом по количеству треугольников может уже легко потянуть на небольшую low poly модельку.

А в некоторых случаях и вовсе никакого эффекта:

Если вспомнить какую-нибудь базовую сцену из оригинальной игры Zombotron и представить, что она будет вся состоять из таких вот криво порезанных спрайтов на кучу треугольников, то можно легко набрать пару десятков тысяч треугольников на один экран, что в целом характерно уже для полноценной 3D игры.

Конечно, не стоит пытаться создавать весь уровень из 100500 маленьких объектов, так как это ни к чему хорошему в любом случае не приведет. Но, лично меня, наличие лишних треугольников для каждого из спрайтов — немного смущает. Я начал изучать эту тему, пытаться как-то настроить алгоритм нарезки в Unity, но в итоге нашел только один вариант — ничего не делать с этим и использовать Texture Packer.

В Texture Packer есть свой более оптимальный алгоритм нарезки текстур на полигоны и он даже имеет некоторые настройки.

На картинке выше представлена полигональная нарезка тех же двух спрайтов алгоритмом Texture Packer без каких-либо настроек (то есть по умолчанию).

Texture Packer пожалуй самый популярный и удобный из известных мне упаковщиков атласов, признаюсь, я даже несколько раз использовал бесплатную версию для упаковки растровых ресурсов для своих Flash игр. Но, расширенная упаковка и нарезка на полигоны — это, к сожалению функция версии программы Texture Packer Pro. Так что тут мне пришлось встать перед выбором: что-то делать самому, или раскошелиться в очередной раз. Я взял триальную версию Pro версии на 7 дней с целью погонять и принять взвешенное решение.

Упаковка ресурсов в целом не составляет никак проблем, накидываем картинок в одну папку, создаем проект в Texture Packer, устанавливаем все необходимые настройки, выбираем для чего экспортировать (поддерживается множество разных фреймворков), и получаем на выход пару файлов: файл атласа и файл с данными о расположении спрайтов на нем.

В случае с Unity, для Texture Packer есть бесплатный импортер атласов в ассет сторе. Нужно только добавить Texture Packer Importer в свой Unity проект, и при добавлении упакованных атласов в проект они автоматически будут импортировать и разбиты так, как мы настроили и видели это непосредственно в самом Texture Packer.

Конечно, в Texture Packer есть еще масса других интересных и полезных настроек, но про них я уже пожалуй рассказывать не буду, дабы не сделать этот пост рекламным, ведь в итоге мне пришлось выложить $39 за этот полезный инструмент. Просто внезапно закончилась триалка, а мне срочно нужно добавить новую графику в проект, куда деваться? :)

Размер текстур для 2D игры

Ну и в завершении этой записи про организацию графических ресурсов, еще расскажу немного о размере текстур. Когда я делал Flash игры — то просто рисовал векторную графику таким же размером, как она должна быть в игре. В случае с новым проектом я решил использовать такой же подход, но при этом экспортировать графику в проект в 2 раза больше, благо вектор это позволяет без потери качества. Но зачем так делать?!

Так уж сложилось, что начиная с 2011 года мы начали переходить в эпоху высоких разрешений экранов, или проще говоря: «Retina» картинка. Это когда точек на дюйм монитора так зашкаливает, что наш глаз уже не видит, и нам кажется, что перед нашими глазами абсолютно четкие линии без каких-либо пикселей. Да что я тут вам рассказываю!? Вы все это уже видели много раз своими глазами! :)

В общем, именно поэтому я решил экспортировать графику в игру сразу в два раза больше, чем она есть на самом деле. В Unity, при создании материалов, есть опция «Generate Mip Maps» — эта опция позволяет включать генерацию разно размерных текстур из оригинальной. Ранее (в далеких 2000х), такой подход использовался для того, чтобы поддерживать разные типы видеокарт: где видео памяти побольше, видео карта помощнее — там и текстуры большие (более детализированная картинка), а где видео карта слабее, видео памяти меньше — там большие текстуры ни к чему, загружаются меньшего размера (текстуры более размытые, меньше деталей). Но, как вот эта опция работает в современном 3D и в особенности в Unity — я пока еще не очень разобрался. Заметил только то, что при включении этой опции я получаю более замыленные спрайты (настройки компрессии настроены как нужно), а при выключении картинка становится лучше. Такое ощущение, что под мой не retina дисплей я получаю текстуры более низкого разрешения, в два раза меньше, чем добавляю в проект.

(Кликните на картинку чтобы открыть в полный размер)

Но моя большая ошибка была в другом: я создавал графику в два раза больше и в таком же виде добавлял её в игру, таким образом все размеры объектов и логику, включая управление — я настроил на заведомо больший размер объектов и когда я захотел добавить текстуры более низкого разрешения, то все объекты становились в два раза меньше. Конечно, размер объектов легко исправлялся изменением параметра «Pixels Per Unit» для текстур, но в этом случае картинка становилась еще хуже.

Хорошо, что я вовремя заметил эту ошибку и добавил еще не так много объектов в игру. В итоге, экспортировал графику в игру 1 к 1, то есть в низком качестве, перенастроил всю физику, исправил все объекты, а потом уже сделал вновь атласы высокого разрешения и добавил их в проект с модификацией «Pixels Per Unit» и тогда картинка стала более четкой и в будущем (если будет необходимость), текстуры можно будет сделать еще более высокого разрешения без перенастройки всех игровых объектов. А с наступлением эры дисплеев высокого разрешения — это скорее всего придется сделать.

Планы на следующую неделю

Часть основной графики я наконец-то нарисовал, с графическими ресурсами вроде разобрался, ошибки прошлых недель исправил и даже что-то уже добавил в проект. Пора приступать к разработке игрового движка: стрельба, разрушения, монстры и прочее. Но тут возникает вопрос: как правильно подойти именно к организации кода в Unity? И это, скажу я вам, не простой вопрос, с этим я планирую разобраться на следующей неделе.

Забегая вперед, напомню, что я уже имею опыт работы с компонентными движками, и я остался очень доволен этим подходом. Поэтому на предстоящей неделе я так же постараюсь рассмотреть движок Unity-Ash и Entitas с целью использовать что-то из этого в своем проекте.

[19 Марта]


Индикаторы: Zombotron3
Постоянная ссылка

 

 

Ну чтож, удачи, Антон)
А я вот перешел с Антхила на Старлинг и пришлось долго разбираться как подготавливать атласы, как импортировать графику и прочее :D
Так что платформы разные - сложности одинаковые)

GreenFest
27 Марта 2016
— 11:01
#

Крутяк :). Картинки луче в пнг добавить, а то разница почти не заметно ибо её съел джипег.

WeslomPo
27 Марта 2016
— 11:29
#

Надеюсь, это не финальный графический стиль. Старая "мультяшная" графика Зомботронов, особенно второй части, мне нравилась намного больше.

Латентный Суперразработчик
27 Марта 2016
— 16:29
#

как всегда - интересно почитать/посмотреть

по поводу новой графики негатива не испытываю, но она - да как-то непередаваемо по родному выглядит

Эльмиго
28 Марта 2016
— 10:44
#

в смысле к новой негатива нет, а преждняя по родному выглядит :)

Эльмиго
28 Марта 2016
— 10:45
#

@WeslomPo, хорошо! Учту на будущее :)

Ant.Karlov
28 Марта 2016
— 11:28
#

@Латентный Суперразработчик,

> Надеюсь, это не финальный графический стиль.

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

Текущая графика тоже как бы мультяшная, просто чуть более строгая по цветам. Но сейчас еще проблема в том, что на картинке в основном детали для заднего плана. А эти детали, как для первых частей, так и для новой игры — однотонные. Когда на переднем плане появится больше деталей, то картинка должна стать ближе по цветам к оригинальной игре.

Ant.Karlov
28 Марта 2016
— 11:33
#

@Эльмиго, здорово, я рад! :)

Ant.Karlov
28 Марта 2016
— 11:33
#

Спасибо! Еще было бы круто видеть гифки по разработке в твиттере, как это сейчас принято у многих)

neelts
28 Марта 2016
— 11:57
#

Круто:)а ты добавишь других монстров,или будут те же зомби мутанты и т.д.И пожалуйста оставь этого монстра мозгоеда:) ,ну,, который ты подходишь а он затаскивает тебя к себе и съедает

фанат
28 Марта 2016
— 13:48
#

языком

фанат
28 Марта 2016
— 13:48
#

Воу! Спасибо вам большое за уроки. Очень познавательно. Вообще уже не один год к вам захожу почитать что да как) Даже помню начинал во флэше кодить по вашим урокам. Рад что всё таки решились переходить на Unity. Удачи вам в этом деле. Мне нравится что у вас получается.
Буду теперь чаще к вам захаживать.
Спасибо.

Максим
28 Марта 2016
— 14:43
#

Мне кажется, пока что очень не хватает фирменной растительности, объектов на разных планах (переплетенных проводов, камней, лучей света) и движущихся фонов. А так да, все стало заметно более угловатое, резкое, строгое и темное, чем раньше. Но это не так бросается в глаза, как отсутствие всех перечисленных фирменных штук Зомботронов.

Латентный Суперразработчик
28 Марта 2016
— 16:06
#

Какая-то дичь про альфу написана. Тормозят не прозрачные картинки, а переключения рендерстейта. Советую сделать тест и просто посмотреть на устройстве.
Чисто на глазок, в Zombotron по филрейту запас примерно x10.

Konstantin
28 Марта 2016
— 16:49
#

@neelts, гифки будут немного по позже. Сейчас разработка находится в такой стадии что контента даже для статичных то картинок нет, не говоря уже о гифках.

Гифки и картинки я публикую в Twitter.com/ZombotronG.

Ant.Karlov
28 Марта 2016
— 17:16
#

@фанат,

а ты добавишь других монстров,или будут те же зомби мутанты и т.д.

Будут старые монстры в новых обличиях, а так же появятся и совсем новые с новыми уникальными возможностями.

И пожалуйста оставь этого монстра мозгоеда:)

Хорошее название "мозгоед"! :D На самом деле этого монстра я сделал вдохновившись монстром Барнакл (Barnacle) из игры Half-Life. Только в зомботроне "мозгоед" выстреливает языком как пулей чтобы поймать жертву, а в Half-Life просто ожидает пока к его языку что-нибудь прилепится.

Ant.Karlov
28 Марта 2016
— 17:21
#

@Латентный Суперразработчик,

> Мне кажется, пока что очень не хватает фирменной растительности, объектов на разных планах (переплетенных проводов, камней, лучей света) и движущихся фонов.

Согласен, мне их тоже очень не хватает и все кажется таким пустым! :) Но я же обещал показывать и рассказывать о ходе разработки с самых ранний стадий. Так вот: именно так выглядит игра на текущей, весьма ранней стадии.

Провода, трубы, устройства, растительность и т.п. — обязательно будут! В этой игре я планирую сделать максимум интерактивных и анимированных объектов на локациях, и как раз по этой причине всех этих объектов сейчас нет. В данных момент я работаю пока только над статической графикой и движком, а все живое начнет появляться немного позже.

Ant.Karlov
28 Марта 2016
— 17:29
#

@Konstantin,

> Какая-то дичь про альфу написана. Тормозят не прозрачные картинки, а переключения рендерстейта.

Согласен! Я нагуглил немного материала на эту тему и выяснил: чем меньше прозрачных пикселей в спрайтах — тем это лучше для мобильных устройств. Но Unity без спроса делает "свою оптимизацию", которая таковой является далеко не всегда. Так что моя основная задача заключалась в том, чтобы избавится от львиной доли треугольников которые плодит Unity.

По рендеру на мобилках я не стал изучать мат часть и разбираться с эти, т.к. в ближайшее время не планирую заниматься разработкой. Поэтому написал весьма просто и доступно как сам понял, ну и чтобы не нагружать игроков следящих за проектом технической информацией которая даже мне по факту не нужна ;)

Ant.Karlov
28 Марта 2016
— 17:37
#

Я знаю, об этом говорить еще СЛИШКОМ рано, однако есть идеи по поводу новых тварей. Если понадобяться, обращайтесь к вашим фанатам!

Кто-то-там
28 Марта 2016
— 18:06
#

А вот здесь могу просто сказать: "Удачи!". Потому что понял лишь половину из написанного) Так что удачи, Антон! Жду не дождусь, когда покажешь разрушения и уничтожение монстров!

SQUASH
28 Марта 2016
— 18:10
#

Спасибо антон, удачи

фанат
28 Марта 2016
— 19:10
#

А труп монстра будет оставаться или исчезать после убийства?,

фанат
28 Марта 2016
— 19:18
#

Классно, Антон!
Удачи и пиши пожалуйста по-больше технических деталей связанных с Unity как тут! А то укушу.

Пантелемон
29 Марта 2016
— 12:32
#

Привет! Может пригодится - Combing Perspective and Orthographic Camera for Parallax Effect in 2D Game

Начинающий нуб
29 Марта 2016
— 12:33
#

@Кто-то-там, когда дело дойдет до монстров, то конечно же я буду рад вашему участию, предложениям и просто комментариям в блоге в отношении монстров ;)

Ant.Karlov
30 Марта 2016
— 10:31
#

@SQUASH,

> Жду не дождусь, когда покажешь разрушения и уничтожение монстров!

Как раз постепенно к этому подвожу. Самому уже не терпится все это увидеть :)

Ant.Karlov
30 Марта 2016
— 10:32
#

@фанат,

> А труп монстра будет оставаться или исчезать после убийства?

На новом движке трупов конечно можно наваливать намного больше, чем это возможно было во Flash. Но я думаю, что трупы должны рано или поздно исчезать, поскольку они полностью физические и большое количество трупов может ломать геймплей (мешать проходимости).

Ничего обещать пока не буду, но если технология будет позволять и геймплей не будет ломаться, то возможно удастся сделать задержку для трупов по больше.

Ant.Karlov
30 Марта 2016
— 10:35
#

@Пантелемон,

> Удачи и пиши пожалуйста по-больше технических деталей связанных с Unity как тут!

Вот, как раз над этим ломаю голову. Получилось так, что в блоге собралось две разные аудитории :) Буду пытаться как-то балансировать на гране технических подробностей и просто интересной информации по разработке и играм. Спасибо!

Ant.Karlov
30 Марта 2016
— 10:39
#

@Начинающий нуб, Вах! Какое интересное решение с тремя камерами. Надо взять на заметку. Я когда экспериментировал с параллаксом в Unity, то делал это по старинке :D Спасибо за ссылку!

Ant.Karlov
30 Марта 2016
— 10:42
#

Мип-мапы работают при удалении объекта от камеры, насколько я понял. Т. е. при создании 2.5D это имеет смысл, если все объекты находятся на одном расстоянии от камеры по Z смысла не имеет.

d-kay
30 Марта 2016
— 12:46
#

А ты какую версию юзаешь?

d-kay
30 Марта 2016
— 13:13
#

Про мип-мапы не корректно.

Они нужны не для оптимизации, а для качества картинки.

То, что они снижают (незначительно и я чё-то вообще сомневаюсь) нагрузку на GPU и дают возможность использовать ЛОДы - приятный бонус.

Мип-мапы требуются для работы различных алгоритмов фильтрации (сглаживания). Например, есть у нас текстура 256х256, а на экране она должна занять размер 16х16 пискселей. Значит её нужно сжать. Мип-мапы - это возможность делать это сжатие не в реальном времени тяп-ляп, а дать возможность художнику самому нарисовать текстуру для такого размера.

1. Point Filtering
Изначально не было сглаживания вообще и текстуры превращались в близи в огромные пискели, а вдали в шум. Это, кстати, единственный режим в котором можно получить Pixel-Perfect для 2D. Мипмапы здесь не нужны.

2. Bilinear filtration. Берём пиксель справа, слева, сверху, снизу и подмешиваем в текущий. Получаем адовое мыло, но без пикселей. Мипмапы здесь не нужны.

3. Trilinear filtration. Берём кроме соседних пикселей ещё и пиксели из разных mip уровней. Получаем не адовое, почти не мыло. Мыло остаётся только на части поверхностей.

4. Анизотропная - делаем хитрое колдунство над мип-ами и мыла почти нет.

Если ты берёшь спрайты, затем их выводишь в 2-раза более низком разрешении, то при трилинейной фильтрации ты видишь фактически бленд из 2-3 картинок (разные мип уровни)

@Ant.Karlov А как ты делаешь mip`ы?

CrazyCoderX
30 Марта 2016
— 14:10
#

Привет! Есть отличная замена TexturePaker`у - бесплатный http://renderhjs.net/shoebox/
Единственный минус - нельзя из командной строки запускать и, как следствие, юзать в скриптах автоматической сборки ресурсов.

x10der
30 Марта 2016
— 14:57
#

@CrazyCoderX, спасибо за разъяснения! С Flash у меня весь мозг атрофировался..

Мип-мапы не влияют на GPU, но должны влиять на видео память. Очевидно, что для моделей которые находятся далеко — не нужно загружать в видео память HD текстуру, достаточно и аналога в наименьшем разрешении.

Вообще я давно работал с 3D уже и многое успел уже позабыть, поэтому могу ошибаться в некоторых вещах — это нормально :)

> А как ты делаешь mip`ы?

Никак, Unity их сам генерирует если не отключить соответствующую галочку в настройках текстуры.

Ant.Karlov
30 Марта 2016
— 17:18
#

@d-kay,

> А ты какую версию юзаешь?

Если версию Unity, то пока 5.2.4. В более поздних версиях у меня на старом рабочем компе отваливается OpenGL и рендер всего (редактора и игры) работает не правильно. Из саппорта написали что ATI Radeon хлам и плохо поддерживает OpenGL версии 3.3 и ниже. Просят обновить драйвера, что принципе невозможно сделать для MacOSX да и не нужно, потому что видео карта старая.

Вот уж не знаю, что там такого намудрили в Unity старше 5.2.4, что вдруг моя видео карта стала плохой! Но вроде обещают исправить — репортами с этой проблемой их вроде завалили нормально так :)

Ant.Karlov
30 Марта 2016
— 17:25
#

@x10der,

> Есть отличная замена TexturePaker`у - бесплатный

Да, замена хорошая. Но, по моему он не умеет делать полигональную нарезку, или я просто не нашел как это сделать? :)

Кстати, за подсказку про командную строку — отдельное спасибо! А то, что-то я уже начинаю уставать собирать все ручками, надо будет разобраться с этим.

Ant.Karlov
30 Марта 2016
— 17:28
#

Кстати, по оптимизации мешей, что насчет вот этого плагина думаете — https://www.assetstore.unity3d.com/en/#!/content/37599? Дешево, сердито, в интеграции с юнити, не нужно колдовать с импортом/экспортом лишний раз.

d-kay
30 Марта 2016
— 17:36
#

В теме "Зомботрон. немного новостей" я написал несколько предложений об третьем зомботроне.
Посмотрите, может что-то покажется интересным.

игрок
31 Марта 2016
— 14:30
#

Отличный новости Антон! Вижу ты не стоишь на месте и прогрессируешь. Очень за тебя рад! Всё же хотел бы тебя предупредить что стилистика у тебя до сих пор похожа на SM. А так вообще всё великолепно! Мне уже нравится будущая игра, прям не терпится поиграть ^^`

Storm
31 Марта 2016
— 21:34
#

@d-kay,

> что насчет вот этого плагина думаете

Думаю что плагин хороший и за свои деньги действительно помогает правится с той подножкой которую ставит Unity :) Но атласы все равно нужно чем-то собирать, так что этот плагин годится только если собирать атласы какой-то сторонней бесплатной программой.

Ant.Karlov
1 Апреля 2016
— 10:42
#

@Storm,

> Всё же хотел бы тебя предупредить что стилистика у тебя до сих пор похожа на SM.

Если честно, то я не очень понял, что вы подразумеваете под словом "стилистика" и о чем предупреждаете.

Для данной игры я стараюсь рисовать графику преимущественно в стиле Sci-Fi с небольшими примесями SteamPunk. И тут очевидно, что в визуальном плане будут отсылки к этим сеттингам (возможные пересечения с визуальным стилем из других игр в этих сеттингах), но это совершенно ничего не значит так как на сеттинг и визуальный стиль невозможно наложить авторские права и как следствие какие-либо ограничения ;)

Ant.Karlov
1 Апреля 2016
— 10:49
#

А в новом релизи UE 4.11 нарезку треугольников для 2D выкатили, может она там даже работает как надо:-)

AlexKLS
1 Апреля 2016
— 12:52
#

У меня кстати есть вопрос о прошлой части. Мы все видели 2 золотые робомашины, но я читал что вы где-то спрятали ещё и Серую. Это действительный секрет или просто гашлёп?

кто-то-там
3 Апреля 2016
— 15:56
#

@кто-то-там, что вы имеете в виду под "робомашиной"? :)

Ant.Karlov
4 Апреля 2016
— 10:09
#

Задам глупый вопрос. Тк я изначально делаю макет уровня в графическом редакторе, то какое расширение экрана оптимально для игры? А то у одних будет мыло, а у других будет мелко.

PRIZRAK
4 Апреля 2016
— 16:33
#

stay cool!

Polovinkin
4 Апреля 2016
— 17:51
#

@PRIZRAK,

> Тк я изначально делаю макет уровня в графическом редакторе, то какое расширение экрана оптимально для игры?

В случае с флеш играми нужно затачивать размер игры на какой-то стандартный экран (не более 800x600). Если речь идет о полноэкранной игре, то оптимально брать среднее разрешение экрана и затачивать игру под него (1920×1080 и 1366×768).

В случае с играми использующими аппаратное ускорение (Unity, Starling и т.п.) — размер экрана не так принципиален, важно сохранять пропорции игры на разных разрешениях. Для этого интерфейс делается "резиновым", а игровая графика растягивается или уменьшается программным путем, обычно такой эффект достигается за счет изменения размеров камеры (зум и фрустум, вомзожно положение). При изменении размеров камеры сама графика визуально не получает практически никаких артефактов. Но все же оригинальные спрайты рисовать желательно в чуть большем размере чем будет сама игра чтобы иметь задел по качеству на будущее (на растущее разрешение мониторов).

Ant.Karlov
5 Апреля 2016
— 10:13
#

Все просто отлично! Скорее бы узнать что ьудет дальше. Все таки у меня из головы не выкладывается вопрос из Zombotron 2 Time Manchine Выжила ли Фина? Ну а пока буду следить )

Виктор
5 Апреля 2016
— 19:42
#

мне зомботрон приснился

игрок
7 Апреля 2016
— 17:20
#

Антон спасибо за ответ! Просто для меня начальные вопросы важны, а спросить не у кого) С Unity не знаком, так что собираю уровень в иллюстраторе. Просто непонятен вот какой момент. Есть размер игрового уровня а есть область отображения (мы же не весь уровень видим). так вот эта область отображения должна быть под разрешение монитора? Те например 1920х1080. А остальной уровень тогда ого-го какой огромный?
Это я к тому что спрайты должны быть большого разрешения.

PRIZRAK
7 Апреля 2016
— 23:22
#

Ну Робомашина... Небольшой бот для фермерских работ.

Кто-то-там
8 Апреля 2016
— 21:05
#

@PRIZRAK,

> так вот эта область отображения должна быть под разрешение монитора?

Да, как-то так. Обычно область отображения называется видимой областью (то что попадает в объектив камеры). Ого-го какие огромные уровни делать не следует по нескольким причинам, наиболее важные:

1. Огроменный уровень может плохо сказаться на производительности. Тут все зависит от того какая игра и как собственно строится и обрабатывается уровень: сколько интерактивных объектов и т.п.
2. Огроменный уровень может плохо сказаться на геймплее. Игроку тоже нужно давать передышки и такой передышкой как раз считаются переходы между уровнями — законченный уровень для игрока это как еще один пройденный этап, как выполненная задача. Поэтому слишком большие уровни могут оказаться очень сложными и тяжелыми "задачами" для некоторых игроков.

Не существует каких-то стандартных оптимальных размеров уровня, все зависит от геймплея и типа игры. Обычно оптимальный размер игрового уровня подбирается геймдизайнером по ходу долгих тестов и экспериментов (в некоторых случаях необходимы даже внешние плей-тесты).

> Это я к тому что спрайты должны быть большого разрешения.

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

Ant.Karlov
9 Апреля 2016
— 14:20
#

Класcно делано я про бывал делать такую игру но у меня сил не хватило!

GOP
26 Мая 2016
— 10:59
#