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

• Чтобы камера следовала за игровым персонажем
• Чтобы камера не выходила за границы карты, а то игрок увидит мир тьмы за пределами игры :) .

Vector3 zero = Camera.main.ViewportToWorldPoint(Vector3.zero);

Vector3 one = Camera.main.ViewportToWorldPoint(Vector3.one);

Как мы все знаем во многих играх разработчикам выбирают для проведения боя пошаговую систему. Такая система пользуется популярностью в пошаговых играх, например, серия игр герои. Я разумеется не буду рассматривать весь механизм работы пошаговой игры, такие моменты как переход от “обычного” режима в режим боя. Все это реализовать будете вы, так как в каждой игре это все выглядит по своему и написать один уникальный скрипт не получится. Хотя, если там будет куча странного кода, то получится, но производительности это не добавит.

Вы можете использовать способ, описанный в этой статье в случае, если в вашей игре враги или что вы там спавните не уничтожаются после смерти при помощи GameObject.Destroy(gameObject), а просто выключается gameObject.SetActive(false). Очередь объектов представляет собой список объектов или массив как вам удобнее, который увеличивается или уменьшается в зависимости от текущей ситуации и требований других объектов в игре (например, триггер, который говорит, что тут необходимо заспавнить врага.

Как не дать объекту выйти за границы экрана или наоборот определить, когда враг появляется в пределах видимости? Последнее конечно проще узнать, проверив видимость Render с помощью функции renderer.isVisible.

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

В настоящие время в Unity есть рекламная сеть Unity Ads, которая работает на последних версиях Unity из коробки, но кому-то может показаться этого функционала мало.

Самым лучший вариант - использовать функционал рекламы от Google (Google AdSense для сайтов и Google Admob для мобильных приложений и игр), которое уже хорошо себя зарекомендовала как среди вебмастеров так и среди разработчиков мобильных приложений (не только Android).

Во-первых, нам нужно зайти на https://www.google.ru/admob, зарегистрироваться, добавить наше приложение в список. Как это делать я расписывать не буду, здесь ничего сложного нет.

И так мы зарегистрировали свое приложение в admob. У нас есть идентификаторы рекламных блоков. Теперь можно приступить к интеграции admob в наш проект unity.

В каких случаях полезно применять очередь объектов вместо их уничтожения? Часто очереди применяют к снарядам (пулям, патронам), другими словами объектам у которых короткая жизни, но и которые требуются регулярно. В таких случаях очень неразумно использовать Destroy и потом заново создать копии объекта из префаба это отнимает много ресурсов и может замедлить игру.

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

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

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

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