Основы многопользовательской игры на Unity3D
Я, как и многие из вас, большой поклонник многопользовательских игр. В них меня прельщает в основном дух соревнования и возможность приобретать улучшения, накапливая достижения. Да и сама идея выхода в свет все большего количества игр данного типа побуждает к действию.
С недавнего времени я и сам взялся за разработку собственного проекта. И поскольку на Хабрахабре статей на эту тематику не нашел – решил поделиться своим опытом написания многопользовательской игры на движке Unity3D. Также хочу рассказать о компонентах Network и NetworkView, атрибуте RPC и встроенных методах-ивентах. В конце статьи подан пример игры и, разумеется, сам проект для Unity. Итак…
Класс Network
Данный класс нужен для организации соединения «клиент-сервер». Основные функции: создание сервера, подключение к серверу, создание сетевого экземпляра префаба.
Основные методы:
Network.Connect (string host, int remotePort, string password = «») – выполняет подключение к серверу host с портом remotePort и паролем password. Метод возвращает перечисление NetworkConnectionError.
Network.InitializeServer(int connections, int listenPort, bool useNat) – создает сервер с максимально разрешенным количеством подключений connections; порт входящих подключений listenPort, а также useNat: использовать либо нет NAT . Также возвращает перечисление NetworkConnectionError.
Network.InitializeSecurity() – вызывается перед Network.InitializeServer() для защиты от читерства. Подробности в официальной документации. Не вызывать на клиенте!
Network.Instantiate(Object prefab, Vector3 position, Quaternion rotation, int group) – создает экземпляр префаба prefab в сети в позиции position с поворотом rotation и группой group. Возвращает весь созданный объект, с которым после создания можно выполнить дополнительные действия. Подробности – далее в статье.
Основные свойства:
bool Network.isClient и bool Network.isServer – определяют, является ваша игра сервером либо клиентом. Оба свойства являются false, если не был создан сервер или не было подключения к серверу.
string Network.incomingPassword – свойство задает пароль для входящих подключений.
NetworkPlayer Network.player – возвращает экземпляр локального игрока NetworkPlayer.
NetworkPeerType Network.peerType – возвращает текущее состояние подключения: Disconnected (отключен), Server (запущен как сервер), Client (подключен к серверу), Connecting (попытка, в процессе подключения).
NetworkPlayer[] Network.connections – возвращает всех подключенных игроков. На клиенте возвращает только игрока сервера.
Основные ивенты (для унаследованного от MonoBehaviour):
OnConnectedToServer() – вызывается на клиенте при успешном подключении к серверу.
OnDisconnectedFromServer(NetworkDisconnection info) – вызывается на клиенте при отключении от сервера и на сервере при завершении подключений Network.Disconnect(). В info содержится причина отключения: LostConnection (потеря связи) и Disconnected (при успешном отключении).
OnFailedToConnect(NetworkConnectionError error) — вызывается на клиенте при ошибке подключения. error содержит ошибку типа NetworkConnectionError.
OnNetworkInstantiate(NetworkMessageInfo info) — вызывается на клиенте и сервере, если был создан новый экземпляр методом Network.Instantiate(). Содержит info типа NetworkMessageInfo.
OnPlayerConnected(NetworkPlayer player) — вызывается на сервере при успешном подключении клиента и содержит player типа NetworkPlayer.
OnPlayerDisconnected(NetworkPlayer player) — вызывается на сервере при отключении клиента и содержит player типа NetworkPlayer.
OnServerInitialized() — вызывается на сервере, после того как сервер был успешно создан.
OnSerializeNetworkView(BitStream stream, NetworkMessageInfo info) — важный ивент для синхронизации компонента с сетью. Подробности – далее в статье.
Класс NetwokView
Данный класс существует также и как компонент для Unity, и предназначен он для синхронизации компонентов в сети и для вызова RPC .
Обладает такими свойствами синхронизации NetworkStateSynchronization:
- Off — не выполняет синхронизацию объекта, однако позволяет вызывать удаленные процедуры.
- ReliableDeltaCompressed — выполняет передачу пакетов поочередно и проверяет, доставлен ли пакет (подобно протоколу TCP).
- Unreliable — выполняет быструю отправку пакетов, не гарантируя доставки (подобно протоколу UDP).
Основные методы:
networkView.RPC(string name, RPCMode mode, params object[] args) — вызывает удаленную процедуру name, mode определяет получателей, args – аргументы для передачи процедуре.
networkView.RPC(string name, NetworkPlayer target, params object[] args) – то же, что и предыдущий метод, однако выполняет отправку конкретному игроку NetworkPlayer.
Основные свойства:
bool networkView.isMine – свойство, определяющее, является ли объект локальным. Весьма часто используется для проверки владельца объекта.
Component networkView.observed – компонент, который будет синхронизироваться. Если это скрипт, то он должен содержать метод OnSerializeNetworkView(BitStream stream, NetworkMessageInfo info), упомянутый выше.
NetworkPlayer networkView.owner – свойство, возвращающее владельца объекта.
NetworkStateSynchronization networkView.stateSynchronization — тип синхронизации: Off, ReliableDeltaCompressed, Unreliable.
NetworkViewID networkView.viewID — уникальный идентификатор в сети для NetworkView.
Атрибут RPC
Метод OnSerializeNetworkView(BitStream stream, NetworkMessageInfo info)
Данный метод используется для синхронизации компонента в сети. Он вызывается всякий раз при получении либо отправке данных по сети.
Вот типы данных, которые могут быть получены/отправлены методом Serialize: bool, char, short, int, float, Quaternion, Vector3, NetworkPlayer, NetworkViewID.
Для проверки, идет ли прием либо передача, используются свойства isReading или isWriting.
Привожу пример использования:
Данный пример не идеален, поскольку при его работе наши объекты будут «дергаться». Чтобы избежать этого, нужно воспользоваться интерполяцией. Подробнее – далее в статье.
Интерполяция
Подробнее о методах оптимизации синхронизации по сети смотрите на сайте разработчиков: Valve Developer Community — Source Multiplayer Networking
Пример многопользовательской игры
Итак, имея представления об основах, можно приниматься за написание небольшой многопользовательской игры. В качестве примеров я использую разные способы применения NetworkView. Вам остается лишь выбрать для себя наиболее удобный способ.
Создаем скрипт ServerSide.cs и пишем туда следующее:
Теперь создаем скрипт клиента ClientSide.cs:
Таким образом, клиентская и серверная логика есть, теперь для нее нужно сделать управление MainMenu.cs:
Управление сетью создано. Далее пишем управление игроком PlayerControls.cs. В данном примере я использую другой способ применения компонента NetworkView:
Знаю, что синхронизация и управление должны находиться раздельно, но для примера я решил объединить их. Как вы заметили, здесь NetworkView создается во время инициализации скрипта. На мой взгляд, это более удобный способ для защиты от возможного «забыл добавить» (разумеется, если не написано RequireComponent( typeof( Rigidbody ))), а также уменьшает в инспекторе количество компонентов на объекте.
К примеру, у меня был случай: когда, на первый взгляд, все было сделано правильно, однако мой скрипт не делал интерполяцию, и все мои действия в синхронизации игнорировал. Так вот ошибкой оказалось то, что Observed был не моим скриптом, а трансформ объекта.
Итак, теперь у нас есть все необходимые скрипты для написания мини-игры.
Создаем пустой объект и назначаем ему скрипты MultiplayerMenu, ServerSide, ClientSide.
Создаем плоскость и немного опускаем.
Создаем префаб игрока (в моем примере это будут шары). Создаем объект «сфера», назначаем ему скрипт PlayerControls и добавляем в префаб. Префаб перетягиваем на ClientSide в поле Player Prefab.
На этом все, компилируем проект (не забывая в настройках игрока включить Run in background) и запускаем несколько раз. В одном из окон жмем сервер, на остальных – клиент, и смотрим на результат.
Ссылка на проект.
*В проекте могут быть логические ошибки, но на суть данной статьи они не влияют.
Всех благодарю за внимание!
Желаю успехов в создании многопользовательских игр!
Источник статьи: http://habr.com/ru/post/211202/
Unity Network. Создание игры с мультиплеером
Unity Network значительная вещь в создании игр, с помощью неё можно создать кооператив в своей игре . Unity Network чаще всего используют в создании мультеплеера до 5-6 человек, далее лучше использовать Photon, с которым мы познакомимся позже. Сегодня же я вам расскажу об основах, вы сможете создавать комнату и использовать простейшие функции. Пример построения кода некоторых функций :
1. Network.InitializeServer(5,2500, true);
С помощью этой функции мы создаём сервер, первое значение отвечает за максимальное количество игроков на сервере, второе это порт, треть отвечать за использование NAT.
2. Network.Connect(«127.0.01», 2500);
С помощью этой функции мы подключаемся к серверу, первое значение это IP сервера, в данном случае используется стандартный локальный ip, второе значение это порт
3. Network.Disconnect();
С помощью этой функции мы отключаемся от сервера.
Вот три самых основных функции при работе с сервером.
Построение комнаты с использованием блока RPC. Пример построения кода :
1. void Update () <
2. if(GUI.Button(new Rect(1,1,1,1), «Start Room»)) <
3. networkView.RPC(«LoadLevel», RPCMode.All);
4. >
5. >
6. [RPC]
7. void LoadLevel() <
8. Application.loadLevel(1);
1- Открываем функцию Update ()
2 — Создаём кнопку «Start Room», и если мы на неё нажмём, то выполнится третья строка.
3- Выполняем блок RPC, в нём выполняем функцию LoadLevel, второе значение отвечает за то, что каким игрокам будет отдаваться эта команда, в данном случаи она будет отдаваться все.
4 — Закрываем условие кнопки.
5 — Закрываем функцию Update()
6 — Открываем блок RPC
7 — Объявляем функцию LoadLevel
8 — Выполняем загрузку 1 уровня
Вот стандартные функции и небольшой пример, надеюсь вам поможет
Дубликаты не найдены
Мне напомнило книги по программированию, большинство такие кстати! Сейчас я вас научу программировать, вот это числовой тип данных integer , а string строковый понятнинько? а вот скобочку в конце нужно ставить, понятненько? ну а теперь нам осталось написать простейший метод
public class FireMissilesDialogFragment extends DialogFragment <
@Override
public Dialog onCreateDialog(Bundle savedInstanceState) <
AlertDialog.Builder builder = new AlertDialog.Builder(getActivity());
builder.setMessage(R.string.dialog_fire_missiles)
.setPositiveButton(R.string.fire, new DialogInterface.OnClickListener() <
public void onClick(DialogInterface dialog, int id) <
>
>)
.setNegativeButton(R.string.cancel, new DialogInterface.OnClickListener() <
public void onClick(DialogInterface dialog, int id) <
>
>);
как все просто да? обьяснить что такое методы классы импорты и т.д. зачем? а хуй знает буду типы данных 50 листов рассказывать
Если ты хочешь сделать пост который приятно читать:
1. Раскрой тему полностью, а не
В Unity легко сделать сетевую игру,
инициализируем сервак,
начинаем слушать сетку,
обновляем канву
2. Даже если тебе каким то образом удалось преодолеть п.1 то вставки кода лучше делать через сервисы pastebin или gist.guthub
3. Прочитав надо закрепить, демку запиливаешь, сорцы на гитхаб, превью на ютуб.
А то что выше это просто из разряда «мама сматри я хелловорлд на хтмл написал«
Как мы разрабатывали части персонажа. Персонаж : правдоподобие против удобства управления
Разработчики находятся в достаточно трудной ситуации. С одной стороны начальство требует дойную корову, которая стабильно работает как автомат калащникова и приносит денежку. C другой стороны таких дойных коров уже изобретено достаточно и в целом все они похожи друг на друга с точки зрения наличия новых уникальных механик и их развития.
На первый взгляд все кажется просто. Вот, на самом деле, почему нельзя просто создать какую-то новую механику, даже много новых механик и улучшать их пока они не устроят? Если что, неудачные механики можно выкинуть 🙂
Разработка игры с новой механикой — это примерно то же самое как работа над открытием или даже процесс поиска клада. Отлично, если вы опытный кладоискатель. Такие кладоискатели знают, что клад вряд ли спрятан в песочнице на детской площадке и не будут его там искать, тратить на это время. Потому что в свое время они уже наступали на эти грабли и ничего там не нашли. То есть существуют механики, которые заведомо неудачны / непригодны для игр. Конечно, все можно адаптировать, видоизменить, подогнать. Но все же существуют вещи которые не следует делать.
Вот рассмотрим очень простой пример такой механики на мобильной игре.
Допустим у нас есть персонаж в мобильной игре и наша задача управлять им. Мы видим персонажа сверху (2D). Как бы в сделали его управление?
Это очень щепетильный вопрос. Управление — это задача задач, которую решают в процессе разработки.
(1) Если вы будете приказывать персонажу идти за пальцем, когда он опущен на экран, то ваша рука будет перекрывать экран и вы будете смотреть на свою руку;
(2) А если персонаж будет идти в противоположную о пальца сторону, то будет ли удобно такое интвертирование управления?
(3) Если персонаж будет идти в точку, которую вы кликнули, то сможет ли он увернуться от летящей ракеты? Не перекроется ли экран рукой, когда вы смените направляение движения персонажа? Это управление точно удобно?
(4) А если просто. Джойстик и все тут! Не перекроет ли джойстик экран? Сколько экранного пространства он занимает (допустимо ли это)? Удобен ли он? Функционален? Позволяет ли он погрузиться в атмосферу игры?
Кто-то скажет: вот вы написали столько всего, так и управления не сделаешь, если все плохои все «неочень». Сделаешь, как раз это частично задача дизайнера интерфейсов, частично дизайнера, отвечающего за управление. Но больше, конечно, задача дизайна управления.
Да, вот такими задачами и занимаются дизайнеры: сделай то, не знаю что, пойди туда, не знаю куда и чтобы все было круто и никак иначе.
Оптыный дизайнер (опытный кладоискатель) способен быстро оценить все «за» и «против» каждого из пунктов 1. Новичок же, очень вероятно, будет экспериментировать и постигать тайны управления с нуля 🙂
Надеюсь теперь стало очевидней, что разработка новой механики — это работа.
Это работа и она не всегда увенчивается успехом. Не всегда даже опытному дизайнеру удается создать новую механику. И это часто зависит не только от дизайнера, но и от команды, от возможностей платформы для которой все разрабатывается.
Дизайнер создает тех. задание, отдает ее на реализацию дизайнерам и программистам, через какое-то время получает результат. Если результат устраивает, то это успех. Если результат не устраивает, то процесс повторяется до того момента, пока инвестору все это не надоест или пока команда не замучается «пробовать». Да, людям не нравится работать, а потом выкидывать свою работу. Особенно, когда ты старательно работаешь и не один месяц. Да, ты получаешь зарплату, но где удовлетворение от проделанной работы? Так и свихнуться недолго, если каждый день все рабочее время выкапываешь, а потом закапываешь выкопанную яму.
Вот потому-то все и идут на ухищрения. Зачем пидумывать что-то новое, когда старое хорошо работает? Возможно нужно немного изменить старое и все будет хорошо?
То, что я написал, касается многих вещей. Не только core-механики. Другие вещи могут быть подвержены этому.
В процессе работы над персонажем всплыло множество моментов, которые требовали такой хорошей и основательной проработки как со стороны дизайнера-программиста, так и со стороны дизайнера по механикам.
В процессе разаработки, было принято решение показыват игроку тело персонажа, чтобы он мог видеть себя своими глазами. Почему нет? Это добавляет атмосферы, смотрится круто.
Мы все фанаты крутого графона и в 21-м веке неприемлимо, когда твоя голова, руки, ноги или пушка влазят в полы или стену или еще куда-то. Нужно было это учесть.
С другой стороны, если персонаж стоит одной ногой на выступе обрыва, то все его тело должно как-то отреагировать на то, что вторая нога в воздухе. А если центр тела персонажа смещен в сторону обрыва, то тут уж 100% нужно это как-то отобразить на персонаже.
Мы справились с этой задачей, сбоку это выглядит так (скрины специально не содержат текстур, дабы не наспойлерить):
По части влияния смещения тела на механику движения: удалось добиться стабильности и минимизировать влияние анимации ног на перемещение игрока.
Ноги опускаются процедурно. Пришлось водключить инверсную кинематику и совместить ее с процедурной анимацией движения всего персонажа. О том как мы анимировали персонажа можно ознакомиться здесь: Процедурная анимация движения персонажа
Получилось весьма недурно 🙂
C руками, как и со всем остальным, отдельная история. И она длинная.
Что требуется от рук? Чтобы они не пересекали стены, чтобы держали пушку. И чтобы это все выглядело нормально. Бывшый мой босс всегда ставил задачу примерно так. Он перечислял все требования до мельчайших и в конце добавлял: «И да, сделайте все это так, чтобы выглядело круто. Просто сделайте так, чтобы все было круто и не заставляйте меня говорить что получился отстой.»
Руки персонажа эволюционировали и прошли очень долгий путь развития. Сперва мы работали над встроенной в руку «спец.пушкой». Всячески безуспешно пытались совместить то, что совместить трудно, да и нужно ли совмещать: руку + пушку + возможность изменения рукой гравитационного поля. Вот пара каких-то ранних скетчей «спец.пушки»:
Подключенные первые варианты рук/манипуляторов выглядел примерно так:
Здесь один из вариантов ранних анимаций. Главное не внешний вид, а принцип работы:
Один манипулятор наехал на другой. Да, такое часто встречалось и приходилось много работать над исключением самопересечения манипуляторов.
Тесты инверсной кинематики. Чисто математика:
А здесь искусственный интеллект нечеловеческими способами учился взаимодействию рукой. Короче, робот как ребенок учился двигать рукой, а на видео некоторые промежуточные результаты, причем неуспешные XD
Инверсная кинематика в чистом виде (IK):
Еще немного инверсной кинематики для тех кому понравились видео:
Здесь эксперименты того как смотрится перемещение обьекта манипуляторами (как манипуляторы ведут себя при перемещении аюстрактного куба):
Навозившись порядочно с манипуляторами, убив тонну времени, сил и нервов, исписав кучу бумаги, мы все же сумели добиться желаемого результата. Финальный вариант на данный момент показать не могу, но могу рассказать к чему мы пришли и как.
Манипулятор мы разделили, условно, на руку (манипулятор) и пушку. Пушка выполняет свои функции, а рука дополняет пушку. Не в воздухе же ей висеть.
Пришлось прописат анимации обхвата пушки рукой и то как рука двигается за пушкой (законы движения, которые позволяют руке не пересекать пушку).
Так же рука может быть и без пушки. Для этого случая мы научили кисть немног взаимодействовать с окружением: если игрок вплотную подходит к стене, то рука как бы занимает промежуточную позицию между стеной и телом игрока. не дает игроку лицом воткнуться в стену. Классно, правда? Так же рука может огибать предметы, если игрок захочет как-то повести себя нестандартно и влезть рукой во что-то.
Когда рука держит пушку, то для этого случая прописаны процедурные анимации движения пушки, которые предостерегают ее от влазания в стены или еще куда-то там. Пришлось порядочно поработать чтобы хитрый игрок никак не смог засунуть пушку туда, куда нельзя.
Некоторые скетчи из процесса разработки игры выкладываю здесь:
Надеюсь статья понравилась и вы почерпнули из нее что-то новое.
ТЬМА ПОГЛОТИЛА ВАС — переделываем мобильный платформер под PC
Полгода назад я уже выкладывал пост о разработке собственного проекта на Unity под Android. Игра не сыскала огромной популярности в плей маркете, но особо сильно меня это не расстраивало, так как большинство поигравших в нее остались довольны.
Многие посоветовали мне идти с данным проектом на площадку компании Valve, так как игры подобного рода намного лучше заходят именно на обычных пк.
Сегодня я расскажу о том, какие изменения я начал вносить в проект для запуска в стиме.
Напомню, что одной из основных механик игры является телекинез, и если быть честным, у меня уже давно чесались руки сделать его более правдоподобным. Как видно на видео ниже, контролируемый объект просто «прилипает» к курсору мыши и следует за ним проходя сквозь абсолютно любые препятствия.
Меня это не устраивало, а потому было принято решение добавить данной механике более реалистичное поведения.
Теперь когда игрок перемещает объект в пространстве, тот не мгновенно следует за указателем, а с помощью определенного вектора силы толкается в направлении курсора. Также теперь объект не может проходить сквозь препятствия, а при столкновении с игроком на определенной скорости убивает последнего.
Как вы могли заметить, при использовании телекинеза появляется эффект хроматической аберрации. Мне показалось, что это будет хорошо выглядеть и подчеркивать необычную способность главного героя.
Сделать данный эффект в своем проекте достаточно просто, так как он входит в стандартный пакет PostFX эффектов для Unity и имеет простую документацию.Если это вас заинтересовало, то вы можете установить его в самом Unity->Window->PackageManager->PostProcessing.
Мы же, двигаемся дальше.
Поговорим о графике. Из-за того, что в начале своего пути проект разрабатывался под мобильные устройства, в игре полностью отсутствует какое-либо освещение. Все световые эффекты достигаются при помощи обычных спрайтов с альфа каналом. На маленьком экране телефона это выглядит достаточно достойно, но при игре на большом мониторе глаза то и дело цепляются за скудность картинки.
Я решил исправить данную проблему с помощью эффекта Color Grading всё того же PostProcessing пакета. Подкрутив пару ползунков я увеличил контрастность картинки и изменил температуру в пользу теплых тонов. Хоть действие игры и происходит в тёмном подземелье, всё же хочется чтоб глазам игрока было приятно.
Также я добавил эффект небольшой дисторсии для того, чтобы картинка в движении выглядела интереснее и живее. Во второй половине ролика снизу видны небольшие искажения по краям экрана. В движении это будет создавать интересный эффект «стеклянной банки».
Изначально игра имела всего десять комнат-уровней с собственными испытаниями, которые должен пройти игрок. При небольшой сноровке все эти комнаты можно пройти за 20-25 минут, что меня совершенно не устраивало. Потому было принято решение внедрить новые механики перемещения в игру и сделать большее количество комнат. Если герой уже обладает телекинезом, то почему бы не добавить ему возможность двойного прыжка? К тому же, данная механика открывает нам возможность делать более сложные комнаты с препятствиями для акробатов.
Что же, если уж начали делать из нашего героя сверхчеловека, то почему бы не пойти дальше? Пусть герой в ходе прохождения научится просто парить по воздуху. Объясним это тем, что с помощью телекинеза он отталкивает себя от земли.
В игре присутствует некое существо, с которым герой вступает в диалог по мере своего путешествия. Опыт с мобильной платформы показал, что игрокам не нравится читать диалоги и большинство предпочитает как можно быстрее пропустить этот момент. Это сподвигло меня изменить работу диалогов и сделать возможность пропускать отдельные реплики героев. Во многих играх разработчики предпочитают озвучивать персонажей в своем стиле. Хорошим примером здесь будет Simlish из симса. Я же решил, что герои моего подземелья должны разговаривать неразборчивым шепотом. Это хорошо вписывалось в общее настроение игры и я незамедлительно вклинил это в проект.
В данный момент в моих планах улучшить озвучку проекта, расширить сюжетную линию, а также сделать полноценное меню и широкие настройки игры. Думаю, что на сегодня это всё, чем я мог бы с вами поделиться. Надеюсь, что в ближайшее время я выложу новый пост, в котором смогу подробнее рассказать о создании самих уровней для игры. Спасибо за внимание 🙂
Процедурная анимация движения персонажа
Этот пост скорее всего не будет полезен профессиональным аниматорам так как они делают анимации на завтрак, обед и ужин. Думаю их этим не удивить. Так же в посте отсутствует мат.часть ибо писал не для того чтобы учить кого-то. Пост в целом для того чтобы показать обобщенное направление работы и полученный мною результат.
Возникла необходимость сделать анимацию персонажа для игры, которую делаю «на коленке».
Ссыли на наработки по игре:
Чем не угодили mocap — анимации:
1) нужно искать наиболее подходящие анимации
3) визуально анимации должны сочетаться
Покопавшись в сети и немного поэкспериментировав с аниматором, пришел к тому, что для создания реалистичной анимации нужно записывать анимацию непосредственно с человека.
Можно брать готовые анимации с https://www.mixamo.com но есть НО:
2) все же урезаный набор анимаций
Побираясь, как бездомный в чьем-то ведре, в поисках нужных анимаций в течении недели я собрал некого Франкенштейна. Именно Франкенштейна потому, что анимаций надыбал отовсюду. Ходил персонаж как офисный работник, крался как эльф 80-го уровня, приседал как человек-паук. Шучу, все было не так уж и ужасно, конечно, для обывателя может и пойдет, а вот меня все же неустраивало разношерстность анимаций. Хотя блендинг и прочие процедурные фишки сильно улучшали дело. Да и ноги не прилипали к земле как надо. Меня это жутко раздражает, когда анимация персонажа не на 100% соответствует тому, что он делает, ноги проходят сквозь пол, руки сквозь стены. ну вы поняли, 21-й век как никак.
Что важно для анимации персонажа: нужно передать ощущение того как персонаж передвигается с учетом физики. Короче, аимация нужна процедурная. Это крайне важно для нашего 3D паззла от первого лица.
Итак поехали. Обобщенно задача состоит в разработке системы анимации персонажа таким образом, чтобы можно было относительно гибко настраивать анимацию под свои нужды (корче, еще раз, чтобы анимация была процедурной).
Для реализации этого, нужно знать что есть инверсная кинематика и уметь ее. Погуглив и ознакомившись собрал простейшую IK, подключил пару костей. Работает. Добавили ограничения, чтобы локти не выворачивались в другие стороны и чтобы кости были похожи на кости. Сделано.
Далее, настало время для машинного обучения. Подключаем обучалку к ногам и обучаем ноги ходить, а руки крутиться. На Github был пример с какими-то бегающими человечками с разным количеством ног. Этот проект лег в основу. Далее не помню как закончил этот адский ад.
В итоге после 2-х недель возни по 12 часов со всей этой ерундой у меня на столе лежал набор как-то дергающихся тестовых конечностей. Кстати, некоторые видео сохранил. Не думал что решу писать об этом пост:
Отлично, цепляем все к боди, еще немного IK и получаем что-то типа (одно из приближений):
Внимание на лодыжку ^. C ней вечно были проблеммы. Дело в том, что наш робот сделан инженерами-конструкторами и соединения должны гнуться строго по оси и никак иначе. Хотя это далеко не последний вариант робота, но в целом все примерно так. (Спойлер: соединение ложыжки мы все же переделали. Инженеры поставили его на 3 гидропривода, что дало нужное число степеней свободы).
Далее используем наш ИИ для ноги. Не зря же нога у нас обучалась ходить сама по себе без тела XD
Подключаем ИИ к ногам и говорим им болтаться:
А теперь ногам приказываем ходить. Здесь нет отклика от пола, ноги не воспринимают коллайдер пола. Иначе роботу на самом деле пришлось бы пойти.
Ну вот все что сделано выглядит вроде и ничего, по отдельности. Когда я соединил все в одно тело, то понял: емое. Позиция ноги, руки, головы (короче, каждой части тела) должна вносить изменение в позицию всего тела и следовательно влиять на другие конечности. Иначе робот ходил как деревянный буратино. Ничего не поделаешь, видать именно так ходят «идеальные» машины лишенные уникальности (уровень робота «Вертер» достигнут!):
Повозившись еще с инверсной кинематикой и мозгами всех частей тела, все же удалось сделать анимацию более естественной.
Здесь экспериментирую с тем как робота придавливает плита. Робот должен корректно анимировать позицию своего тела:
На вторые руки не обращайте внимания. Сделал доп.пару рук чисто для себя, для сравнения того как разные алгоритмы будут обрабатывать стену.
Что хотелось бы добавить. Полностью избежать использования mocap анимации не удалось. Почему так? Дело в том, что роботу нужна индивидуальность, стиль перемещения. именно для этого ему даются наборы анимаций с которых он перенимает пластику движения и испоьзует ее при расчете процедурной анимации перемещения. Как-то так.
В тестах использовалась модель-аналог робота Федора. Извините, это неточная копия. Чертежей не было, собрали «на глаз» XD
Blueprints и C++ в Unreal Engine: плюсы и минусы
Epic Games последовательно развивает систему визуального программирования Blueprints в Unreal Engine. Она продвигается как полноценная рабочая среда, в которой любой новичок может освоиться и собрать свою игру. Но действительно ли «блюпринты» ни в чём не уступают классическому программированию?
Александр Балакшин, программист AAA-игр, внёсший значительный вклад в разработку сезонных обновлений для Tom Clancy’s Rainbow Six Siege в роли старшего инженера-разработчика и лида геймплейной команды, разбирает плюсы и минусы Blueprints и объясняет её отличия от «чистого» C++.
Блюпринты выигрывают у C++ на начальных этапах разработки, особенно если код игры пишется с нуля. Они не требуют установки дополнительной среды, к тому же предлагают быстрые итерации. А блочный синтаксис блюпринтов понятен не только программистам, но и тем, кто знаком с аналогичными системами в программах для создания контента — например, художникам.
Но если рассматривать разработку игры в целом, в долгосрочной перспективе, то классический подход к программированию показывает свои преимущества. Даже сами Epic Games заостряют внимание на том, что блюпринты — это не код, а данные, поэтому и относиться к ним нужно соответственно. Например, некоторая общая логика всё равно должна выноситься в код.
По этой же причине блюпринты невозможно толком «мёрджить», то есть соединять результаты разработки. Поэтому их приходится отдельно блокировать, чтобы не создавать конфликтов и не терять проделанную работу. С классическим же кодом могут работать даже несколько человек одновременно, но результат их работы в одном файле обычно всё равно очень просто совместить.
Наконец, блюпринты бьют по производительности, так как компилируются в байт-код, который работает на встроенной в движок виртуальной машине. Да, их можно нативизировать, — то есть преобразовать Blueprint-логику в файлы C++, но даже разработчики из Epic рекомендуют этим не злоупотреблять.
Да и с точки зрения GOMS-анализа нажатие на клавишу клавиатуры оказывается быстрее, чем перемещение мышки. Это ни в коем случае не отменяет удобство визуального редактора, но, по моему опыту, с автодополнениями и прочими синтаксическими функциями современных IDE писать код удобнее и быстрее, чем создавать граф в блюпринтах. Хотя полезные сочетания клавиш и шорткаты в Unreal Engine тоже облегчают жизнь.
Я считаю, что если программисту нужно работать с Tick-функциями, или он использует какую-то сложную математику и пространственные запросы (например, LineTrace), всё это лучше вынести в С++. Отчасти из-за всех перечисленных особенностей Epic Games раздумывают над созданием отдельного скриптового языка для реализации игровой логики в Unreal Engine.
Тем не менее, блюпринты — достаточно мощный инструмент, который в Unreal Engine 4 используется не только для построения игровой логики, но и для работы с анимацией и системой эффектов Niagara. Поэтому каждая студия должна сама найти подходящий баланс между Blueprints и С++. Например, технические дизайнеры Riot Games использовали блюпринты в Valorant только для создания способностей игроков.
Сами Epic Games рекомендуют использовать блюпринты, когда в проекте очень много ссылок на контент, а его логика работает в первую очередь на визуальную составляющую. Также они пригодятся в создании прототипов, прямолинейной или редко используемой логики, которая не является частью основной архитектуры. Всё, что не получит преимуществ в С++ с точки зрения производительности, масштабируемости и стабильности, тоже может быть создано в Blueprints.
Ну а с С++ лучше работать, если функционал используется более чем в одном месте и включает в себя сложные элементы — например, сохранение игр или сетевой код. Если проект в дальнейшем будет расширяться, то его тоже лучше создавать с помощью классического программирования — оно помогает тщательно поддерживать логику и стабильность кода.
Словом, с любыми важными переменными, перечислениями и типами данных C++ работает лучше. Но и работа в Blueprints не отменяет классический подход, а только органично дополняет его в необходимых случаях. Так что разработчикам от визуального программирования никуда не деться.
LEVEL UP! В этот раз Unity, C# и Hyper Casual. Опыт, советы и история. Indie Gamedev Development, от идеи до продакшена
Привет, разработчики! Меня вы можете знать(узнать) по серии постов про мою первую игру и первый неуспешный неуспех, вот последний: «Пикабу-эффект». Слитые 300$ на мотивированные скачивания и App Removed после пары часов в топе.
Немного расскажу вам всякого про GameDev и меня в нём, постараюсь наполнить чем-то лаконичным, интересным и хоть немного полезным.
Что ж, забавно конечно теперь смотреть на свою первую игрульку спустя время, вроде и неловко за такое, а вроде и какая-то теплота и ностальгия в душе. Хоть и не так давно это было, но Unity сильно поменял моё представление об уровне и качестве игр, которые я могу делать в одиночку (прошлую, напомню, делал нативно в андроид студии на джаве).
Да, как я и обмолвился о своих планах в последних постах(10 месяцев назад), я перешел на игровой движок. Выбор оказался простым, а эффект сильным. Такой значительной разницей в лёгкости работы я был удивлен(деленной на качество и скорость). Сразу скажу, 3d брать не стал, наверняка в 3d делать игры тяжелее.
После небольшого перерыва, взялся кодить дальше. Юнити осваивал по видеоурокам, начал с этого: https://www.youtube.com/watch?v=14g8mA4lVQs . И по кусочкам разбирался с другими темами с разных каналов, покажу, какие нашел.
— https://www.youtube.com/channel/UCIabPXjvT5BVTxRDPCBBOOQ — развлекательно-информационный канал про геймдев. https://www.youtube.com/user/SykooTV — еще один.
Из русскоязычных я бы выделил вот эти:
некоторые фичи и компоненты делал полностью по этим видеоурокам, остальные излишне развлекательные и не особо полезные в практическом плане.
Короче, подписан и откусывал знания я именно с этих каналов.
После 2х недель обучения сразу сел за практику и начал делать то, ссылку на что вы найдете в конце.
Идею игры придумывал еще неделю. В прошлой игре я занял самую слабую по всем показателям нишу викторин, поэтому в этот раз решил взять самый популярный сейчас жанр гиперкэж. Ну и буду честен дальше, пошел на SensonTower и начал искать популярные игры с высоким показателями Revenue, чтобы сделать что-то похожее на них. Нашел, Ball Blast от вуду, и самому понравилось, и топ ревенюе у неё тогда был(90к $ в месяц). Платформу выбрал iOS и android.
Придумал, что сделаю такую же, только самоидентичную и в горизонтальной ориентации. Ну и начал. Делал по вечерам и выходным (работал и все еще работаю). Где-то за месяц накидал прототип, потом на 3 месяца выпал из жизни и вообще ничего не делал по игре, развеялся, собрался с мыслями. И вернулся, вернулся, и за 3 месяца вечеров и выходных закончил работу. Скажу, что звучит красиво, но если вы новичок и только задумываетесь об игровой индустрии, не совершайте ошибку многих и не романтизируйте GameDev, я не приходил после работы домой и не делал игру под сериалы и с бокалом вина, работать и учиться пришлось много и усердно. Мои блокнотные записи с просчетами баланса и прочим прототипированием на бумаге выглядели так(на фото примерно половина):
Ну-с, перейду к советам, которыми хотелось бы поделиться, опыта много, но постарался выбрать из него тот, который оказался для меня неявным и на поиск которого я потратил время.
1) Ооооочень с неожиданной стороны подкрался подводный камень. Регистрация аккаунта разработчика в App Store. У Apple с осени 2019 года появилась проблема во внутреннем эквайринге, и оплату за аккаунт просто не снимает с карточки(с любой, совсем с любой). Подробнее можно почитать тут: https://vc.ru/dev/101224-apple-developer-program-problemy-s-. . Проблема есть до сих пор, и многие с ней сталкиваются, я тоже столкнулся и застрял на этом этапе на 2 недели(мне еще мало, некоторые по 2-3 месяца мучаются). Решение — писать и общаться с суппортом, проблему действительно решают, но придется поговорить письмами. Советую сразу описывать проблему и просить перевести на Senior Adviser-а. А у него уже просить либо Wire Transfer(банковский перевод) либо чтобы они вручную сняли с вашей карты оплату. Я решил вторым вариантом. Поэтому, советую начинать регистрировать аккаунт в dev.Apple раньше.
2) Снова Apple, застрял надолго. Если при попытке загрузки билда в App Store вас автоматически реджектит и приходит письмо что вы используете устаревший UIWebView в проекте, а вы его не используете — то просто обновите юнити, и все пройдет)). Это же касается и «очень странных проблем», касающихся не конкретно вашего кода, а поведения JDK, NDK и разных SDK.
3) Снова Apple, на этот раз попался в самом конце, уже когда игра попала в релиз, встроеные покупки. Внутренняя система в App Store Connect довольно запутанная и необычная, для того, кто имеет с ней дело в первый раз. Да, в интернете есть множество гайдов и туторов, даже официальный неплохой. Но как раз из-за запутанности порядка правильных действий, какой-то можно упустить + некоторые моменты вообще не описаны и неинтуитивно понятны, и ответы приходится искать на stackoverflow и черпать из ответом людей.
Оказалось, что для всех внутренних покупок нужно приложить скриншот этой покупки из игры для каждого айдишника, и описание. Я этого не понял, и пришлось быстро всё чинить, иначе покупки не работали.(тестовые из sandbox-a работали прекрасно и без задоринки, не подумайте).
К слову сказать, при отправке иcправленной версии, я воспользовался функцией ускоренной проверки в App Store, вот ссылка на форму, которую не так просто найти самостоятельно: https://developer.apple.com/contact/app-store/?topic=expedit.
Эта штука работает, и работает отлично, я указал причину critical bug-fix и версию проверили за пол дня, отреджектили, я внёс исправления, снова отправил, и версии получила статус Approved уже через час! То есть баг был исправлен и залит в магазин в течении одного дня, прекрасный результат!
4) Скачайте себе asset в Unity на автосейв. Почему-то сам движок в такое не умеет. Сами понимаете после чего я установил его себе..
5) В юнити есть прекрасный Unity Collaborate, с которым очень просто и удобно(и бесплатно) работать с разных рабочих мест или с кем-то.
6) Большое количество Rigidbody сильно тормозит сцену, особенно заметно на слабых устройствах. Если вы управляете объектом через Translate, то в Rigidbody ставьте ему body type — kinematic, иначе для них будет продолжать высчитываться физика и грузить процессор.
7) Отключайте Raycast Target у элементов UI, которые не должны реагировать на нажатия. При каждом нажатии на экран, движок будет пробегаться по всем всем элементам UI которые есть на сцене и у которых включен Raycast. Мне это неплохо помогло.
8) Группа в телеграмме unity3d.ru. Не бойтесь задавать там вопросы, там хорошие ребята и часто помогают, познакомился с хороши людьми именно там, и именно там встретил человека, который бесплатно и помог мне с музыкой и звуками. Это как форум, но только не приходится ждать ответа днями, либо тебе кто-то поможет, либо спроси еще раз через пару часов. Там же у них есть и группа геймдев-юристов и маркетологов, короче, полезное место.
9) Не знаю, правильно ли называть это советом, но скажу так, хоть опыт геймдева в андроид студии был интересным, но лучше бы я начала сразу с юнити)). Было бы гораздо эффективнее и удобнее. Если ваша цель создавать игры, подобные этой и многим подобным( а у меня изначально была именно такая цель), то начинайте сразу с юнити, это легко, быстро и интересно!
Еще хотелось бы рассказать небольшую историю про графику в игре. Абсолютно всё графику, пушки, юай и фоны и иконку нарисовала моя 15-летняя сестра в Adobe Illustrator. Она всегда любила рисовать, на бумаге, а я подкинул ей идею изучить адоуб. Сестра попробовала, и у неё все получилось, и очень сильно превзошло мои ожидания. Мы отлично сработалоись, я получил очень простую в организации работу с художником, а Катя получила первый практический опыт в деле, которое ей нравится, который так трудно получить в школах и универах. Получила огромное количества интереса и первые честно заработанные деньги)). Это событие стало очень неожиданным и крайне важным для меня и для неё, укрепило наши немного слабые отношения и многому обоих научило. И я очень счастлив по этому поводу!
Друзья, на этом пока что всё. Задавайте вопросы, буду отвечать.
И отдельно хочу сказать спасибо всему сообществу и всем вам за то, что вы так тепло отреагировали тогда на мои истории. Ваша поддержка играет большую роль в моей вере в себя и то что я делаю. Контент был не особо интересный и качественный, но вы поддержали, а я потом, если честно, все 10 месяцев это вспоминал и представлял как напишу сюда после про свою игру, когда выпущу её. Вот и написал.
Вот тут можно бесплатно скачать и посмотреть на мою игру (аккаунт в гугл плей новый, старый сломался):
Всем, кто дочитал, хороших и продуктивных выходных! Спасибо за внимание.
Alien: Hope For The Future. Как все начиналось и какое будущее ждет
Всем привет. В данной статье я решил рассказать вам о проекте более обширно, нежели просто делиться сухими фактами. Здесь я раскрою: что это за проект, зачем он нужен, чем он выделяется, и чем он важен лично для меня. Надеюсь, данная информация окажется полезной и интересной для вас.
С самого первого знакомства со вселенной Чужого, а оно началось еще в детстве с первой части 1979 года, меня покорили тайны этого мира, пустота космоса и стиль ретро-футуризма. В то время не было еще толком интернета, и различных книг и комиксов было не достать (и слава богу).
Поэтому тайна мертвого инопланетного пилота на Дереликте, происхождение самого Чужого, его мотивы, поведение и т.д. вызывали много вопросов и подогревали интерес еще больше.
Как говорил Альфред Хичкок: «Нет ничего страшнее закрытой двери».
К сожалению, в последних фильмах и расширенной вселенной, эту дверь постоянно, не то что открывают, а выламывают, но мы сейчас не об этом.
Второй фильм вселенной, режиссера Джеймса Кемерона, «Чужие» 1986 года, для меня никогда не являлся «упрощенным боевичком», как считают многие. Он расширил вселенную именно с той стороны, с которой и следовало, а именно, место человечества в этом пустом космосе. Корпорации, терраформирование новых планет, колонии, колониальная морская пехота и т.д. И, конечно же, оставил небольшую загадку, которую можно раскрыть, не нанеся вред загадочности вселенной. А именно, как выживали жители колонии «Надежда Хадли» во время инцидента с ксеноморфами.
Этот временной промежуток давно интересовал меня. Книга «Река Боли», а так же комикс «Newts Tale» лично меня не впечатлили, т.к. было слишком много несостыковок с фильмом. Да и вообще, выставлять на первый план историю любовной интрижки матери Ньют была не лучшей идеей.
Занявшись изучением в свободное время геймдева и получив хоть какие-то первоначальные знания в этом, долго придумывать идею для проекта не пришлось.
Проект позиционирует себя как работа фаната для фанатов, он не коммерческий.
Помимо самореализации, опыта и известности в узком кругу фан сообщества, я врядли получу из него какую-то выгоду, да и не планирую.
Движок у игры Unity3d. Его начинал изучать, на нем делал первые наработки, да и другой движок, unreal, мой ноутбук тянул с натяжкой. (Кстати говоря, работаю до сих пор на том же ноутбуке 7-летней давности).
Жанр Immersive sim с элементами стелс-хоррора и тактики не самый легкий вариант для самоучки одиночки, но ничего другого для проекта по чужому я даже не рассматривал.
Самым дорогим ресурсом изначально и по сей день является время, его категорически не хватает.
В начале разработки использовалось очень много примитивов и бесплатных моделей. Да и с визуалом толком не умел работать. Что не шло проекту на пользу. Глазу явно не к чему было зацепиться, и мало кто верил в проект.
Изначально для меня было самым важным раскрыть историю именно колонистов, их быт и выживание. Чужие, скорее, катализатор. Но это не значит, что они менее важны, просто раскрывать их каким-либо образом, не описанным в первых фильмах, желания не было. Помимо интересной истории для меня не менее важна каноническая составляющая проекта. Да весь мой сюжет это, по сути, фанфик, не имеющий под собой никакой силы. Но все же, основополагающим пунктом является то, чтобы после прохождения игры можно было бы смотреть фильм Кемерона как логичное и бесшовное продолжение истории без каких-либо несостыковок. В игре важно раскрытие каких-то элементов, узнаваемость мест и событий, которые морпехи с Сулако не застали, а лишь предполагали, что же там произошло.
С самого начала работы над проектом (март 2017), произошло только одно значительное изменение в сюжете. Изначально планировалось, что главный герой будет новеньким в колонии, приехавшим работать по контракту. Это обыгрывало бы незнание игрока местности и других колонистов. Также был выбор специальности героя. Но это усложняло добавлению глубины и личности проекту. По сути, в итоге вышел бы очередной инди-хоррор бродилка с фонариком.
Неизменный костяк проекта.
Пока прорабатывался сюжет и основные механики сюжета, были проделаны первые работы по лвл-дизайну. Начал работу, конечно же, с Южного комплекса, где происходили основные события фильма. А это: Командный центр, мед лаборатория и т.д.
Основные референсы брались из фильма и игры Aliens: Colonial marines (простите меня за это, но тогда у меня не было выбора)
На данный момент все основные пункты, такие как сюжет, главный герой, геймплей и т.д. утверждены и непоколебимы. Помимо основной компании, будут также 3 дополнительные, небольшие сюжетные ветки, которые будут выходить как демо.
Во-первых, это более обширное раскрытие начала инцидента, с разных точек зрения, мест и социальных групп. Так, например, в одной мы будем играть за простого инженера, в другой за представителя администрации, в третей за представителя охраны колонии. Все это поможет более детально раскрыть те события и проработать каждый пункт геймплея отдельно.
Во-вторых, в каждой из демо прорабатывается свой, отдельный геймплей, а это: элементы Immersive sim-а, Стелс-хоррор и тактика, которые соединятся в основной компании.
В чем раскрываются все эти жанры в игре:
Immersive sim: Во-первых, это право выбора и нелинейность – концовка может быть одна, но прийти к ней можно по-разному. Во-вторых, в игре достаточно много времени будет уделено еще живой колонии. Я хочу показать обычный рабочий быт этого места, это позволит добиться полного погружения в события. Люди будут заняты своим делом, вы сможете поговорить со всеми. У колонистов будут свои характеристики, и одна из основных — это психологическое здоровье. Если у NPC этот статус на низком уровне, и при этом вы не пытаетесь его успокоить, то в критический момент он может впасть в истерику, зашуметь в неподходящий момент, бросить вас, или даже пожертвовать вами, чтобы спастись самому.
Survival-horror: Тут ничего необычного. Вам придется бороться за свою жизнь и жизнь близких в месте, которое когда-то стало для вас домом. Прятаться, находить пропитание и предметы для крафта, помогать или нет другим колонистам. В общем, выживать.
Тактическая составляющая еще прорабатывается, но в нее точно будут входить: набор и командование колонистами для вылазок за припасами и поиска убежищ (тут как раз будет очень важным психологическое состояние тех, кого берете), тактическая расстановка людей при обороне сейф зоны, для успешного отхода колонистов и уменьшения потерь. Непосредственное распределение задач для баррикады самой сейф зоны (можно сделать все самому, но времени может не хватить).
В 2018 вышла тестовая демо за одного персонажа, она была не оптимизирована, забагована, графически очень устаревшая, но людям понравилось.
Сейчас в разработке демо с стелс-хоррорной составляющей. В ней прорабатывается искусственный интеллект Чужого. А для проекта это один из важнейших пунктов.
Чужой должен быть чужим. Ведь как бы я не любил Alien: Isolation, но если убрать прекрасный лвл- дизайн, выполненный в стиле первого фильма, в голом остатке у нас будет тривиальный геймплей и чужой, модель которого замени на любого другого монстра, и ничего не поменяется.
Модель чужого далась мне очень не просто. Я не профессионал в 3д моделировании, думаю любой спец, увидев сетку модели, не сможет спать неделю) Но выбор у меня был не велик, и, в принципе, я доволен финальным вариантом.
Пока что чужой в колонии один. И он любопытен. ГГ не является исключительной целью чужого, как это часто бывает в играх. Он изучает свои угодья. Ползает по стенам и потолкам, прячется в тени, играет со своими жертвами, и уносит их туда, где никто не услышит их крик. Поведение Чужого, сперва в одиночку, а потом в группе, это то, что делает его узнаваемым для любого фаната, даже если он не видит чужого, но знает что тот где то рядом. Вот то, чего я постепенно пытаюсь добиться. И в этом есть успехи.
Впереди еще много работы. Чужой должен будет взаимодействовать и с Нпс, выламывать двери. Кислота будет проедать объекты, не все, но механика уже тестировалась.
Выход ближайшей демо рассчитан не позднее 26 апреля, на День Чужого. После этой демо работа пойдет в разы быстрее. Основная работа будет над НПС, озвучкой и лвл дизайном.
Зачем нужен этот проект, в конце все всё равно умрут.
Учитывая, что все прекрасно знают, чем все закончилось в колонии, сильно я никого не удивлю. Для меня главное – история людей, борющихся за свою жизнь и жизни близких. Как все происходило и как именно все закончилось. Будут какие то неожиданные твисты, которые поймут только истинные фанаты. Быть может, все пойдет немного не так, как все думали. Но альтернативных всеобщих хеппи эндов не будет. Ничего, что хоть как-то конфликтует с каноном фильма Чужие, в проекте не будет.
Проект, в первую очередь нужен для меня. Но если находятся люди, которым тоже это интересно, и готовы поддержать проект даже морально, это придает большой стимул к работе.
Проект живет, и дойдет до финала несмотря ни на что. Надеюсь вам понравится моя версия тех событий.
За проектом следят много фанатов за рубежом. А так же разрабы Alien: blackout и Керри Хенн (Ньют из фильма).
Очень часто проходят стримы по проекту, на них я работаю, отвечаю на вопросы по проекту и вселенной Чужих.
Если вы не равнодушны к этой вселенной, присоединяйтесь ко мне в группах, на стримах и т.д.
Вместе мы построим лучшие миры!
Unity предоставляет три месяца бесплатного доступа к Unity Learn Premium в связи с вирусом COVID-19
С 19 марта по 20 июня открыто все и вся, куча обучающего материала, от вас только зарегистрироваться на офф сайте.
Отличный шанс начать хоть что-то делать, если вы давно хотели начать работать с Unity.
С начала движухи прошло уже больше недели, но как показала практика, мало кто об этом знает.
Делюсь архитектурным шаблоном (StarterKit) для Unity проектов
Периодически я пилю тут посты, которые с переменным успехом то набирают плюсы, то набирают минусы)))
Сегодня хочу поделиться шаблоном (в некотором роде «стартеркит») Unity-проекта, подходящего почти для любой игры. Набросал его для одной из инди-команд сообщества «Индикатор».
В основном это архитектура пользовательского интерфейса и логика загрузки сцен. И, конечно же, простой аудио-контроллер. И менеджер кастомных событий, что бы помочь новичкам избегать глупостей вроде постоянного отслеживания здоровья Игрока в методах Update какого-нибудь компонента-счетчика здоровья.
В репозитории (ссылку приведу в конце) используется как собственный код, так и сторонний (NonDrawingGraphic, UIParticleSystem).
Сейчас это шаблон с примером реализации Главного Меню (назову это «Экраном») и появляющегося окна (назову это «Диалогом»).
Произвольные экраны и диалоги — это префабы со своей реализацией родительских классов ScreenController и DialogController. В случае диалогов, если не требуется выполнять никаких особых, не предусмотренных классом-родителем, действий — то можно использовать родительский класс без ущерба функциональности.
Логика следующая — существует главная сцена с контроллерами/менеджерами. «Главный Игровой Контроллер» при загрузке игры (появлении этой сцены при запуске) отображает загрузочный экран (назову это «Прелоадером»).
Затем (не реализовано, т.к. это индивидуально для каждого проекта) предполагается чтение/загрузка настроек, конфигураций, файлов-сохранений и пр.
После этого вызывается экран «Главного Меню», который загружает необходимую ему сцену (разумеется, оставляя первую «главную» сцену активной), включает музыкальный фон и убирает «Прелоадер».
Надеюсь, кому-нибудь пригодится.
Удачи и успеха всем в геймдеве!
Another realm v0.06
Итак, пришло время очередного доклада о прогрессе разработки.
За последний месяц я окончательно закончил работу над ближним и дальним боем, пофиксил все видимые баги и немного оптимизировал производительность, освоился с новым ИИ, добавил дийствия обнажения и вложения оружия в «ножны», добавил активную паузу(а точнее замедление), и, наконец, приступил к системе магии. В этом посте расскажу побольше о последнем.
Предистория (можно пропустить)
Планировать систему магии я начал уже давно, поэтому на её реализацию до нынешнего состояния у меня ушло не больше недели. Учитывая, что я не мог выделять много времени каждый день и то, что не малую часть времени ушло на попытки перейти к системе «разработки через тестирование» (test-driven development), я считаю, что справился весьма не плохо. Я начал чувствовать, что мои знания и навыки как в области геймдева в целом, так и программирования выросли на порядок, с тех пор как я начал разработку. Если кого-то интересует мой опыт разработки через тестирование в юнити и почему я пришёл к заключению, что лучше не использовать данную методику в этом проекте, могу написать об этом отдельный пост.
Компонентная система заклинаний.
Заклинания в мой игре это по сути комбинации различных компонентов, что позволяет создавать невероятное разнообразие заклинаний из небольшого количества компонентов. Так же эту систему можно будет внедрить в геймплей и позволить игрокам создавать собственные заклинания на подобие того, что было в морровинде и two worlds 1/2. Каждый компонент представляет из себя скриптовый объект( далее «со»), имеет свою реализацию функции «выполнить» и настройки которые он использует в этой функции. При использовании заклинания в сцене создаётся (или активируется из пула) объект, который инициирует и запускает заклинание(я называю его spellEngine или движок заклинания). Его задача в том, чтобы инициировать и проследить за выполнением всех компонентов заклинания и уничтожить(или вернуть в пул) все что с ним связано по завершению. Движок раздаёт компонентам ссылки на себя и следующий компонент в очереди и запускает выполнение первого компонента. Так же он запускает любые корутины, о которых его просят компоненты и следит за ними, чтобы знать, когда все компоненты закончили выполнение. Каждый компонент принимает ссылку на заклинателя, цель, начальную и конечную позицию и использует эти данные по своему усмотрению, а в конце выполнения, запускает выполнение следующего компонента и передаёт ему такие же данные. Весь сок в том, что компонент может изменять передаваемые данные, вызывать следующий компонент несколько раз или с задержкой. Например, компонент АОЕ находит все цели в определённом радиусе от цели и запускает следующий(а следовательно и все последующие) для каждой цели. Компонент «повторитель», запускает следующий компонент по той же цели несколько раз с опциональной задержкой. Компонент «снаряд» создаёт физический снаряд или спецэффект, которые летит в сторону цели или следует за ней и в конце передаёт новую позицию, как из начальную следующему компоненту. Компоненты имею опцию быть параллельными. В таком случае они запускают следующий компонент сразу, не дожидаясь окончания своей функции.
На данный момент имеется 5 компонентов: Урон, визуальный эффект, снаряд, повторитель и область действия. Каждый компонент имеет дополнительную настройку, поэтом можно очень быстро создать новые варианты компонентов. Все это создает очень гибкую систему создания заклинаний. Из минусов, разве что, сложность балансировки всевозможных вариантов заклинаний с точки зрения геймплея.
На данный момент в ближайших планах добавить ещё один компонент: «силу» (имеется ввиду термин из физики, force). Данный компонент позволит отбрасывать, притягивать и подкидывать персонажей и другие предметы применяя к ним физическую силу.
Интересно услышать от вас идеи для будущих компонентов. Возможно, что-то мне понравится и я реализую это в игре.
Напомню так же, что я до сих пор ищу соратников по разработке. Несколько человек связались со мной ранее и даже кое чем помогли, но активно в разработке, они все же не участвуют. Если у вас есть интерес к проекту и вы имеете опыт/желание приобрести опыт в ниже описанных областях геймдева, напишите об это в коммента, либо найдите мои контактные данные в предыдущих постах.
Требуются:
-3д моделер
-3д аниматор
-создатель спецэффектов
-создатель интерфейса
-иллюстратор/художник
(можно несколько в одном лице. Опыт и знания не обязательны если у вас есть желание обучаться и вы готовы тратить несколько часов в неделю на проект)
Источник статьи: http://pikabu.ru/story/unity_network_sozdanie_igryi_s_multipleerom_2804846