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 Марта]
Крутяк :). Картинки луче в пнг добавить, а то разница почти не заметно ибо её съел джипег.
Надеюсь, это не финальный графический стиль. Старая "мультяшная" графика Зомботронов, особенно второй части, мне нравилась намного больше.
как всегда - интересно почитать/посмотреть
по поводу новой графики негатива не испытываю, но она - да как-то непередаваемо по родному выглядит
в смысле к новой негатива нет, а преждняя по родному выглядит :)
@WeslomPo, хорошо! Учту на будущее :)
@Латентный Суперразработчик,
> Надеюсь, это не финальный графический стиль.
Не знаю пока. Все еще рисую сам, смотрю и думаю нравится оно мне или нет. Но в большей степени я конечно сейчас сосредоточен на геймплейной части и освоении новых инструментов.
Текущая графика тоже как бы мультяшная, просто чуть более строгая по цветам. Но сейчас еще проблема в том, что на картинке в основном детали для заднего плана. А эти детали, как для первых частей, так и для новой игры — однотонные. Когда на переднем плане появится больше деталей, то картинка должна стать ближе по цветам к оригинальной игре.
@Эльмиго, здорово, я рад! :)
Спасибо! Еще было бы круто видеть гифки по разработке в твиттере, как это сейчас принято у многих)
Круто:)а ты добавишь других монстров,или будут те же зомби мутанты и т.д.? пожалуйста оставь этого монстра мозгоеда:) ,ну,, который ты подходишь а он затаскивает тебя к себе и съедает
языком
Воу! Спасибо вам большое за уроки. Очень познавательно. Вообще уже не один год к вам захожу почитать что да как) Даже помню начинал во флэше кодить по вашим урокам. Рад что всё таки решились переходить на Unity. Удачи вам в этом деле. Мне нравится что у вас получается.
Буду теперь чаще к вам захаживать.
Спасибо.
Мне кажется, пока что очень не хватает фирменной растительности, объектов на разных планах (переплетенных проводов, камней, лучей света) и движущихся фонов. А так да, все стало заметно более угловатое, резкое, строгое и темное, чем раньше. Но это не так бросается в глаза, как отсутствие всех перечисленных фирменных штук Зомботронов.
Какая-то дичь про альфу написана. Тормозят не прозрачные картинки, а переключения рендерстейта. Советую сделать тест и просто посмотреть на устройстве.
Чисто на глазок, в Zombotron по филрейту запас примерно x10.
@neelts, гифки будут немного по позже. Сейчас разработка находится в такой стадии что контента даже для статичных то картинок нет, не говоря уже о гифках.
Гифки и картинки я публикую в Twitter.com/ZombotronG.
@фанат,
а ты добавишь других монстров,или будут те же зомби мутанты и т.д.
Будут старые монстры в новых обличиях, а так же появятся и совсем новые с новыми уникальными возможностями.
? пожалуйста оставь этого монстра мозгоеда:)
Хорошее название "мозгоед"! :D На самом деле этого монстра я сделал вдохновившись монстром Барнакл (Barnacle) из игры Half-Life. Только в зомботроне "мозгоед" выстреливает языком как пулей чтобы поймать жертву, а в Half-Life просто ожидает пока к его языку что-нибудь прилепится.
@Латентный Суперразработчик,
> Мне кажется, пока что очень не хватает фирменной растительности, объектов на разных планах (переплетенных проводов, камней, лучей света) и движущихся фонов.
Согласен, мне их тоже очень не хватает и все кажется таким пустым! :) Но я же обещал показывать и рассказывать о ходе разработки с самых ранний стадий. Так вот: именно так выглядит игра на текущей, весьма ранней стадии.
Провода, трубы, устройства, растительность и т.п. — обязательно будут! В этой игре я планирую сделать максимум интерактивных и анимированных объектов на локациях, и как раз по этой причине всех этих объектов сейчас нет. В данных момент я работаю пока только над статической графикой и движком, а все живое начнет появляться немного позже.
@Konstantin,
> Какая-то дичь про альфу написана. Тормозят не прозрачные картинки, а переключения рендерстейта.
Согласен! Я нагуглил немного материала на эту тему и выяснил: чем меньше прозрачных пикселей в спрайтах — тем это лучше для мобильных устройств. Но Unity без спроса делает "свою оптимизацию", которая таковой является далеко не всегда. Так что моя основная задача заключалась в том, чтобы избавится от львиной доли треугольников которые плодит Unity.
По рендеру на мобилках я не стал изучать мат часть и разбираться с эти, т.к. в ближайшее время не планирую заниматься разработкой. Поэтому написал весьма просто и доступно как сам понял, ну и чтобы не нагружать игроков следящих за проектом технической информацией которая даже мне по факту не нужна ;)
Я знаю, об этом говорить еще СЛ?ШКОМ рано, однако есть идеи по поводу новых тварей. Если понадобяться, обращайтесь к вашим фанатам!
А вот здесь могу просто сказать: "Удачи!". Потому что понял лишь половину из написанного) Так что удачи, Антон! Жду не дождусь, когда покажешь разрушения и уничтожение монстров!
Спасибо антон, удачи
А труп монстра будет оставаться или исчезать после убийства?,
Классно, Антон!
Удачи и пиши пожалуйста по-больше технических деталей связанных с Unity как тут! А то укушу.
Привет! Может пригодится - Combing Perspective and Orthographic Camera for Parallax Effect in 2D Game
@Кто-то-там, когда дело дойдет до монстров, то конечно же я буду рад вашему участию, предложениям и просто комментариям в блоге в отношении монстров ;)
@SQUASH,
> Жду не дождусь, когда покажешь разрушения и уничтожение монстров!
Как раз постепенно к этому подвожу. Самому уже не терпится все это увидеть :)
@фанат,
> А труп монстра будет оставаться или исчезать после убийства?
На новом движке трупов конечно можно наваливать намного больше, чем это возможно было во Flash. Но я думаю, что трупы должны рано или поздно исчезать, поскольку они полностью физические и большое количество трупов может ломать геймплей (мешать проходимости).
Ничего обещать пока не буду, но если технология будет позволять и геймплей не будет ломаться, то возможно удастся сделать задержку для трупов по больше.
@Пантелемон,
> Удачи и пиши пожалуйста по-больше технических деталей связанных с Unity как тут!
Вот, как раз над этим ломаю голову. Получилось так, что в блоге собралось две разные аудитории :) Буду пытаться как-то балансировать на гране технических подробностей и просто интересной информации по разработке и играм. Спасибо!
@Начинающий нуб, Вах! Какое интересное решение с тремя камерами. Надо взять на заметку. Я когда экспериментировал с параллаксом в Unity, то делал это по старинке :D Спасибо за ссылку!
Мип-мапы работают при удалении объекта от камеры, насколько я понял. Т. е. при создании 2.5D это имеет смысл, если все объекты находятся на одном расстоянии от камеры по Z смысла не имеет.
А ты какую версию юзаешь?
Про мип-мапы не корректно.
Они нужны не для оптимизации, а для качества картинки.
То, что они снижают (незначительно и я чё-то вообще сомневаюсь) нагрузку на 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`ы?
Привет! Есть отличная замена TexturePaker`у - бесплатный http://renderhjs.net/shoebox/
Единственный минус - нельзя из командной строки запускать и, как следствие, юзать в скриптах автоматической сборки ресурсов.
@CrazyCoderX, спасибо за разъяснения! С Flash у меня весь мозг атрофировался..
Мип-мапы не влияют на GPU, но должны влиять на видео память. Очевидно, что для моделей которые находятся далеко — не нужно загружать в видео память HD текстуру, достаточно и аналога в наименьшем разрешении.
Вообще я давно работал с 3D уже и многое успел уже позабыть, поэтому могу ошибаться в некоторых вещах — это нормально :)
> А как ты делаешь mip`ы?
Никак, Unity их сам генерирует если не отключить соответствующую галочку в настройках текстуры.
@d-kay,
> А ты какую версию юзаешь?
Если версию Unity, то пока 5.2.4. В более поздних версиях у меня на старом рабочем компе отваливается OpenGL и рендер всего (редактора и игры) работает не правильно. ?з саппорта написали что ATI Radeon хлам и плохо поддерживает OpenGL версии 3.3 и ниже. Просят обновить драйвера, что принципе невозможно сделать для MacOSX да и не нужно, потому что видео карта старая.
Вот уж не знаю, что там такого намудрили в Unity старше 5.2.4, что вдруг моя видео карта стала плохой! Но вроде обещают исправить — репортами с этой проблемой их вроде завалили нормально так :)
@x10der,
> Есть отличная замена TexturePaker`у - бесплатный
Да, замена хорошая. Но, по моему он не умеет делать полигональную нарезку, или я просто не нашел как это сделать? :)
Кстати, за подсказку про командную строку — отдельное спасибо! А то, что-то я уже начинаю уставать собирать все ручками, надо будет разобраться с этим.
Кстати, по оптимизации мешей, что насчет вот этого плагина думаете — https://www.assetstore.unity3d.com/en/#!/content/37599? Дешево, сердито, в интеграции с юнити, не нужно колдовать с импортом/экспортом лишний раз.
В теме "Зомботрон. немного новостей" я написал несколько предложений об третьем зомботроне.
Посмотрите, может что-то покажется интересным.
Отличный новости Антон! Вижу ты не стоишь на месте и прогрессируешь. Очень за тебя рад! Всё же хотел бы тебя предупредить что стилистика у тебя до сих пор похожа на SM. А так вообще всё великолепно! Мне уже нравится будущая игра, прям не терпится поиграть ^^`
@d-kay,
> что насчет вот этого плагина думаете
Думаю что плагин хороший и за свои деньги действительно помогает правится с той подножкой которую ставит Unity :) Но атласы все равно нужно чем-то собирать, так что этот плагин годится только если собирать атласы какой-то сторонней бесплатной программой.
@Storm,
> Всё же хотел бы тебя предупредить что стилистика у тебя до сих пор похожа на SM.
Если честно, то я не очень понял, что вы подразумеваете под словом "стилистика" и о чем предупреждаете.
Для данной игры я стараюсь рисовать графику преимущественно в стиле Sci-Fi с небольшими примесями SteamPunk. ? тут очевидно, что в визуальном плане будут отсылки к этим сеттингам (возможные пересечения с визуальным стилем из других игр в этих сеттингах), но это совершенно ничего не значит так как на сеттинг и визуальный стиль невозможно наложить авторские права и как следствие какие-либо ограничения ;)
А в новом релизи UE 4.11 нарезку треугольников для 2D выкатили, может она там даже работает как надо:-)
У меня кстати есть вопрос о прошлой части. Мы все видели 2 золотые робомашины, но я читал что вы где-то спрятали ещё и Серую. Это действительный секрет или просто гашлёп?
@кто-то-там, что вы имеете в виду под "робомашиной"? :)
Задам глупый вопрос. Тк я изначально делаю макет уровня в графическом редакторе, то какое расширение экрана оптимально для игры? А то у одних будет мыло, а у других будет мелко.
stay cool!
@PRIZRAK,
> Тк я изначально делаю макет уровня в графическом редакторе, то какое расширение экрана оптимально для игры?
В случае с флеш играми нужно затачивать размер игры на какой-то стандартный экран (не более 800x600). Если речь идет о полноэкранной игре, то оптимально брать среднее разрешение экрана и затачивать игру под него (1920×1080 и 1366×768).
В случае с играми использующими аппаратное ускорение (Unity, Starling и т.п.) — размер экрана не так принципиален, важно сохранять пропорции игры на разных разрешениях. Для этого интерфейс делается "резиновым", а игровая графика растягивается или уменьшается программным путем, обычно такой эффект достигается за счет изменения размеров камеры (зум и фрустум, вомзожно положение). При изменении размеров камеры сама графика визуально не получает практически никаких артефактов. Но все же оригинальные спрайты рисовать желательно в чуть большем размере чем будет сама игра чтобы иметь задел по качеству на будущее (на растущее разрешение мониторов).
Все просто отлично! Скорее бы узнать что ьудет дальше. Все таки у меня из головы не выкладывается вопрос из Zombotron 2 Time Manchine Выжила ли Фина? Ну а пока буду следить )
мне зомботрон приснился
Антон спасибо за ответ! Просто для меня начальные вопросы важны, а спросить не у кого) С Unity не знаком, так что собираю уровень в иллюстраторе. Просто непонятен вот какой момент. Есть размер игрового уровня а есть область отображения (мы же не весь уровень видим). так вот эта область отображения должна быть под разрешение монитора? Те например 1920х1080. А остальной уровень тогда ого-го какой огромный?
Это я к тому что спрайты должны быть большого разрешения.
Ну Робомашина... Небольшой бот для фермерских работ.
@PRIZRAK,
> так вот эта область отображения должна быть под разрешение монитора?
Да, как-то так. Обычно область отображения называется видимой областью (то что попадает в объектив камеры). Ого-го какие огромные уровни делать не следует по нескольким причинам, наиболее важные:
1. Огроменный уровень может плохо сказаться на производительности. Тут все зависит от того какая игра и как собственно строится и обрабатывается уровень: сколько интерактивных объектов и т.п.
2. Огроменный уровень может плохо сказаться на геймплее. ?гроку тоже нужно давать передышки и такой передышкой как раз считаются переходы между уровнями — законченный уровень для игрока это как еще один пройденный этап, как выполненная задача. Поэтому слишком большие уровни могут оказаться очень сложными и тяжелыми "задачами" для некоторых игроков.
Не существует каких-то стандартных оптимальных размеров уровня, все зависит от геймплея и типа игры. Обычно оптимальный размер игрового уровня подбирается геймдизайнером по ходу долгих тестов и экспериментов (в некоторых случаях необходимы даже внешние плей-тесты).
> Это я к тому что спрайты должны быть большого разрешения.
Графику всегда лучше рисовать чуть больше чем она нужна для игры в итоге, а потом немного уменьшать. Но скэйл так же может плохо сказаться на качестве в итоге (некоторые детали могут превратится в кашу после небольшого скейла). Все это, конечно, зависит от опыта художника. С вектором в этом плане намного проще: рисуем 1 в 1, а потом можно скейлить в любую сторону. Но лучше до скейла отдельных объектов не доводить и рисовать все в одном, заранее определенном масштабе.
Ну чтож, удачи, Антон)
А я вот перешел с Антхила на Старлинг и пришлось долго разбираться как подготавливать атласы, как импортировать графику и прочее :D
Так что платформы разные - сложности одинаковые)
27 Марта 2016
— 11:01
#