Как я работаю с триггерами в Unity

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

Триггеры работают прекрасно, пока вы не начинаете требовать от них всякий маразм. Мой маразм заключается в том, что объект, который вошел в триггер, не всегда может оттуда выйти, он может просто сгинуть посредством Destroy прямо в этом триггере. И события OnTriggerExit не произойдет. Если это какая-то дрянь, которая окрашивается красным, если в нее кладут, например, кубик, дрянь останется красной, если кубик уничтожить без выноса оного из этой дряни.

Честно говоря, в случае какой-то особенной дряни я не использую триггеры. Я использую функцию Physics.OverlapSphere, которая в нужный мне момент генерирует в нужной точке пространства сферу-триггер с нужным мне радиусом, после чего возвращает массив всякой фигни, которую эта сфера наперекрывала. Делать это я могу реже или чаще, обладаю относительно полным контролем, то есть. Мне почему-то кажется, что вызывая эту функцию реже, я экономлю какие-то ресурсы процессора. Скорее всего, это все шизофрения или, как минимум, менингит, потому что таких сфер я генерирую в количестве максимум 6 штук, ну что тут можно наэкономить?

Но есть ситуации, когда кастовать сферу для проверки какого-то объема нецелесообразно. Например, объем, который нужно проверить кодом, разный, а код один, или объем – плоский, и сфера сюда не подходит. Например, есть у нас торчащие из пола кусочки бумаги (“что за херню делают эти ребята???”), если положить на них кубик, они войдут в него, как горячий нож в сливочное масло, а если вошел не весь кусочек, он будет неприятно торчать из кубика у его основания. Делать кусочек физическим – не круто, кубики должны ложиться на пол ровно. Было решено сделать кусочки триггерами, которые могут визуально пропадать, если почувствуют, что в их объем попал кубик. И все прекрасно, кидаем на кусочки кубик, триггеры кусочков, на которые попал кубик, генерируют событие OnTriggerEnter, в котором мы сам кусочек исчезаем. Если же у триггера случилось событие OnTriggerExit, кусочек появляем. Выглядит хорошо, пока мы не решим уничтожить кубик. Событие OnTriggerExit не сработает, кусочек, на котором лежал кубик перед уничтожением, не появится.

(Я только что осознал, что вполне могу получить комментарий, типа: “а, ламер, вот же событие, которое генерируется триггером, если в нем был уничтожен какой-то объект!” Как бы – конфуз. Ну и ладно, хоть кто-то научится чему-то из этого поста).

У триггера есть событие OnTriggerStay, которое генерируется, если в триггере что-то имеется. Как бы это дело и использовать? – подумал я.

Спустя какое-то время скрипения мозгом, придумалось вот что.

(Не густо придумалось, надо сказать.) Это переменные класса. Назначение смотрим ниже.

Ниже – функция OnTriggerEnter, которая будет вызвана, если в триггер что-то попало. Если триггер уже был активирован, ничего не делаем, возбуждаемся только если триггер неактивный. Первым делом активируем триггер флажком _isTriggered, а потом реагируем триггером на вход в него чего-то.

Функция FixedUpdate. Она вызывается движком перед обработкой OnTriggerStay функции (может быть вызван реже, чем Update(), которая вызывается каждый кадр, может чаще), если триггер активирован, просто сбрасываем флажок _isStay; собственно, эта функция нам нужна только потому, что она вызывается строго перед OnTriggerStay.

Функция OnTriggerStay, которая вызывается, если в триггере что-то находится (вызывается для каждого объекта, попавшего в триггер, но нас это не тревожит). Просто устанавливаем флажок _isStay в true.

Функция LateUpdate. Вызывается после (на самом деле, нет) обработки движком всех физических событий. Нас мало волнует так ли это, самое главное, что эта функция не будет вызвана МЕЖДУ FixedUpdate и OnTriggerStay. В LateUpdate мы проверяем – не тру ли наш флажок вызова OnTriggerStay. Если не тру, значит, OnTriggerStay не вызывалась, значит, в триггере ничего больше нет, реагируем триггером на выход (или на исчезновение) из него всех объектов. И сбрасываем флажок активности триггера.

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

Не знаю, почерпнули ли вы что-то полезное из этой простынки, и надеюсь, что в Unity это сделали.

Всем пис.

Немного лжи (из блога игры Verge, русский вариант)

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

Еще раз – это неправда.

Серьезно, не верьте мне.

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

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

Пойду спрошу, не уходите никуда.

 

(английский вариант)

Первый пост (из блога игры Verge, русский вариант)

Добро пожаловать в блог о создании игры “Verge“. Бла-бла-бла, бла-бла-бла, бла-бла-бла.

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

Мы – это два с половиной человека (на самом деле, три. На самом деле, нет.). И еще FDG Entertainment. Первый человек – это я, Евгений Кузьмин. Меня вы можете знать по играм “Ragdoll Cannon“, “Roly-Poly Cannon” и “Cover Orange“. Второй – Владимир Гусев. Его вы можете знать по играм “Roly-Poly Cannon“, “Cover Orange“, “300 Miles to Pigsland” и “All we need is Brain“. Половинка человека – Леша Бабай. Его вы можете знать по мультфильму “Кочет i курiца” (смотреть строго на работе в присутствии начальника). Половинка он потому что первые двое сидят в одной комнате и пилят игру из нее, а Леша работает с комнатой издалека. А еще совсем недавно к нам присоединилась Ressa M. Schwarzwald. Кто за что отвечает будет описано позже.

И еще есть FDG Entertainment. Их вы тоже можете знать.

Казалось бы, что все эти люди могут сделать из грустной идеи про человека в коме, который решает головоломки?

Оказалось, что могут сделать игру. И скоро доделают. А пока этого не случилось, постараются развлечь вас рассказами о разработке. Любая разработка – это скука большую часть времени, но остальную часть иногда выходит смешно и интересно. Про это и расскажем.

P.S. Посты могут делать разные люди, поэтому, если вы увидите еще одно “Добро пожаловать в блог о создании игры”, это нормально, возможно это Филипп из FDG решил поприветствовать вас менее неформальным способом.

 

(английский вариант)

Игра Verge

Несколько дней назад мы запустили блог нашей игры. Располагается тут: vergethegame.com

Туда пишу я, Филипп (FDG-Entertainment) и Владимир Гусев (VladG).

Пока опубликовано три поста, но уже два ждут своего часа. Вчера планировалось опубликовать новый пост (где Владимир рассказывает о левелдизайне), но блог решил сломаться на уровне dns-провайдера. Пришлось поколдовать, и вот блог снова в строю.

Пишем мы там по-английски. Вернее, я-то заготавливаю посты на русском, Владимир (он умеет) переводит на английский, а Филипп редактирует (он умеет). Если я буду писать по-английски сам, это будет нелепо и смешно, решили, что лучше не надо. Посты получаются несколько отцензурированными Филиппом, наверное, это правильно, неподготовленные могут быть отпугнуты от блога потоком моего сознания. Но русские версии моих постов пропадают. Как вы думаете, стоит ли выкладывать их сюда, если вдруг среди читателей имеются люди, которых английский текст расстраивает больше, чем русский?

Про Азуру

Раз нужен блог, нужен и хостинг. Этот блог хостится у Микрософта с помощью чудо-штуки под названием Azure.

(это не реклама, если Микрософт начнет платить мне деньги вместо того, что я ему плачу, виниловый Стив Джобс у меня на обоях перекрестится)

Азура – это про облака. Все, что вы мастерите в Азуре, вы мастерите в облаках.

Вот что можно смастерить:

a1

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

a2

WordPress тоже есть, как без него.

Самое прекрасное в Азуре это то, что можно на ходу изменять масштаб виртуального сервера, где крутится ваш сайт. Почувствовали, что посетителей стало больше и выделенных мощностей не хватает, двигаете ползунок, увеличиваете мощность, минута на применение изменений, и вот уже блог готов к еще одной сотне тысяч посетителей. Конечно, Микрософт исправно будет брать за возросшую на них нагрузку деньги. Иначе пока никак. Кажется, там есть возможность автомасштабирования, если, например, вы знаете, что по ночам на ваш сайт заходит только Гугл, а остальные боты спят, на ночь выделенные мощности можно понижать автоматически. Точно не знаю, пока еще не пробовал, я же деньги не считаю.

Но это все про хостинг.

Когда мы приступили к работе над проектом, нам понадобилась система версий для юнити. У юнити есть своя, ее и решили использовать. Asset Server должен был крутиться на внешнем сервере (наш художник, он же моделлер, работает удаленно), в связи с чем я вспомнил об азуре. Микрософты дают возможность запилить виртуальную машину в облаке. Также, кстати, с возможностью масштабирования на лету. Лично я выбрал самую убогую конфигурацию, Asset Server вполне работает и на такой. Называется конфигурация А0, общее ядро (не знаю, что это значит), 768 мегабайт оперативной памяти, стоит аренда такого калькулятора пятьсот рублей в месяц. На виртуальную машину можно было поставить много всякого, даже Убунту:

a3

Мак Озь не давали, пришлось поставить Windows Server 2008. Слово Server немного настораживало, ведь я во всем этом еще хуже, чем в английском языке. Но, как оказалось, все было небольно. После небольшой возни, Азура сказала, что сервер готов, можно пользоваться. Я запустил Remote Desktop (для мака, кстати, тоже есть) и получилось вот что:

a4

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

Виртуальную машину можно выключать прямо из панели управления Азуры. И вы не платите деньги за то время, пока виртуальная машина выключена. Если бы я выключал свою виртуальную машину на ночь и на все выходные, она стоила бы мне всего рублей 200 в месяц, но я же деньги не считаю.

И еще одно про виртуальные машины. Собрать в Азуре можно очень неслабую конфигурацию. 16 ядерную со 112 Гб оперативной памяти (на самом деле, можно и с 32 ядрами и 448 Гб оперативки, но мне такое чудовище пока не дают создавать, полагаю, что из-за санкций того, что оно пока еще тестируется). Это, конечно, стоит солидных денег. Если убогое А0 стоит 60 копеек в час, А9 с 16 ядрами и 112 гигабайтами оперативной памяти стоит уже почти 170 рублей в час. Сколько будет стоить G5 с 32 ядрами, боюсь даже представить.

Зачем все это?

Уровней в нашей игре будет 45 штук, и мы, типа как правильные девелоперы, будем использовать лайтмаппинг. Для комнаты с дверью, скрины которой я показывал в прошлых постах, запекание теней занимает на моем ядерном реакторе 4 минуты. А это мощный ядерный реактор:

a5

А на А9, который с 16 ядрами и 112 гигабайтами, это занимает уже 2 с небольшим минуты. В два раза быстрее. Учитывая, что запекание – штука частая, времени будет отъедать немало. С 45 уровнями можно провозиться немало. Конечно, 32 ядра могли бы и полторы минуты выдать, но пока так. Всего за 170 рублей в час. И никакой возни – на виртуальной машине устанавливается юнити, присоединяется к системе версий проекта, а после запекания запеченное отправляется всем участникам проекта. К слову, А9 – это еще и мощный интернет-канал, полуторагигабайтный дистрибутив юнити, например, скачивается виртуальной машиной всего за несколько секунд. Если бы еще можно было устанавливать на виртуальную машину Windows XP или Windows 7, было бы совсем хорошо (серверные винды помешаны на безопасности, задают при каждом удобном и неудобном случае массу глупых вопросов).

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

Так и работаем.

Про название и про блог игры

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

Еще FDG (FDG Entertainment – это мои издатели) сказали, что нужен блог про разработку игры. Филипп показал блог игры Thimbleweed Park, которую мастерит Рон Гилберт, и сказал, что так делают, и что так делать – круто. Раз круто, будем делать такой спец-блог. Вести его будем вместе с FDG, наполнен он будет скринами, мыслями, реализованными и нет идеями. Ругаться про Юнити, наверное, будет нельзя, поэтому ругаться про Юнити буду по-прежнему здесь. Будем стараться, чтобы блог был и на русском, и на английском. С английским у меня особые отношения, поэтому переводить мои русские напевы про игру на английский будет VladG, а я буду помогать ему переводить на русский напевы Филиппа. Конечно, будет тратиться ценное время, которое могло бы быть с пользой употреблено на саму еще незавершенную игру, но FDG меня убедили, что эта затея не менее ценная.

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

Такие дела.

И последнее о "The Talos Principle"

Добили таки. Наиграли больше 25 часов, так что, если решитесь на все загадки и секреты, запасайтесь временем. Мы с VladG собрали все звезды и посмотрели все концовки. Всех секретных мест не видели, всех документов не прочитали (секретные места там такие секретные, что без подсказок их просто не найти, документы – жуткая ахинея и белиберда). Несколько раз пользовались интернетом (создалось впечатление, что вещи, вроде скрытого лазера, который можно только нащупать на далеком объекте, а не увидеть, сделаны именно для того, чтобы их искали в интернете).

В целом – хорошо. Если бы не разрабатывали подобную игру, могли бы сказать – очень хорошо.

Но не замечательно и не отлично.

“Тетрис”, который нужно собирать, чтобы открывать некоторые двери (даны тетрисовые кусочки, которые нужно втиснуть в определенный объем), скоро настолько надоедает, что становится пыткой.

jpg

Звезды, которые иногда находятся в очень неожиданных местах, даже не на самих уровнях, собирать интересно, хоть и не все – логично (это и есть – минус). Такие виды можно наблюдать в процессе:

v

Самый большой минус – однообразие. В середине игры просто устаешь от монотонного повторения одних и тех же действий, которые ты повторял на предыдущих уровнях уже много раз. Из-за этого игра воспринимается не как сочная выжимка из геймплейных элементов, где со вкусом подано самое оригинальное, игра воспринимается как утомительное размазывание одного и того же вперемешку с сомнительными решениями. Поэтому играть в нее полезнее с перерывами и понемножку.

Так что: Portal, Quantum Conundrum, The Talos Principle, Q.U.B.E., Antichamber такой порядок. Будем пробовать уместиться между второй и третьей.

e

Про Unity3d

Все знают, как я люблю Unity3d. Особой любовью, она может напоминать игру «Dead Space» или даже фильм «Paranormal Activity». Наши отношения похожи на брак малолетней пары, которая женилась только потому, что глупая девчонка забеременела от глупого мальчишки. И гуляют рядом свободные и интересные, а тебе каждое утро приходится жить с ненавистным уже человеком.

Забегая к концу, скажу сразу: если я делаю 3Д игру в Unity3d, это совсем не значит, что я буду Unity3d советовать всем начинающим. Советовать и рекомендовать я буду только Unreal Engine 4. А от Unity3d 4 бегите, какими бы словами не заманивали. Оговорюсь, что не знаю, как обстоят дела с 2Д в Unity, по отзывам, вроде, даже неплохо. Но я также и не знаю, как обстоят дела с 2Д в UE4. 

Я слишком погряз в юнити, переходить на анрил долго, затратно и нервно. Уже вложено огромное количество средств и сил, придется допиливать с тем, что есть. Но, например, кооперативную часть (а в нашей игре появятся и кооперативные уровни) я точно будут начинать на UE4. Если, конечно, не произойдет чуда и Джон Ричитьелло не совершит невозможное. Что-то внутри подсказывает мне, что не совершит.

Что же не так. Ниже – немного гадостей.

(да, я буду говорить гадости. У меня куплена лицензия на юнити и еще подписка на юнити. А сколько потрачено денег в assets store… Так что, да, когда платишь очень немалые деньги за то, чтобы потом заниматься костылестроением, можно и гадости)

 

Префабы.

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

Все круто, правда?

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

Предположим, у вас есть отличный префаб. Годно настроенный, сказка, а не префаб. И захотелось вам сделать его составной частью другого, нового префаба. Например, есть у вас лампочка, которая умеет загораться и тухнуть. И захотели вы сделать префаб Бра, в который, конечно, вам хочется добавить свою лампочку, сделать, то есть, ее дитем Бра. Что вы делаете. В игровой объект Бра тащите из библиотеки объект КлеваяЛампочка. И КлеваяЛампочка становится чайлдом Бра. Потом переносите Бра в библиотеку, и клевый префаб Бра готов. Теперь, если вы перенесете Бра на новую (или старую) сцену, он будет добавляться вместе с КлевойЛампочкой, ведь лампочка теперь чайлд Бра навеки. Здорово, правда?

Еще раз. В библиотеке у вас теперь имеется префаб КлеваяЛампочка и префаб Бра, внутри которого есть КлеваяЛампочка. Когда я впервые это открыл, со мной случилось то, что случилось с терминаторшей из третьего «Терминатора», когда она нашла на полу кровь Джона Коннора. Это ж какие возможности! Это ж ООП, мать его в коньках за босу ногу! Но Джон Коннор остался жив, а терминаторшу убили. Если вы думаете, что изменение параметров префаба КлеваяЛампочка хоть как-то повлияет на параметры объекта КлеваяЛампочка в префабе Бра, ошибаетесь вы. Не повлияет. КлеваяЛампочка внутри префаба Бра – это теперь совсем другая КлеваяЛампочка. И если вы придумали какой-нибудь КлевыйЦоколь для своей КлевойЛампочки, добавлять его вам придется и в КлевуюЛампочку префаба Бра тоже.

Не забывайте про эту фичу. Мне эта фича дорого обойдется. Теперь я понимаю что имел в виду портал app2top в посте про игровые движки о минусах юнити: «процесс изготовления игры отнимает много времени».


Cache Server.

Юнити позволяет билдить вашу игру на разные платформы. Это очень круто. Пара движений, и игра запускается на Windows, MAC OS, iOS, Android и даже в web browser. 

Нет, я сейчас не о том, что на самом деле все не слишком радужно. Запускаться – запускается, мне, кстати, очень понравилась сборка билда для Android (быстро и без лишних переходных процессов вроде запуска Xcode, если билдить для iOS).

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

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

Эта штука входит в Team Licanse, то есть, за нее нужно платить. 

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

 

Asset Server. 

Система контроля версий. Не используйте. Используйте другое. К счастью, Юнити это умеет.

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

 

Мелочь.

При работе в 3Д пространстве юнити, вы можете использовать правую кнопку мыши и клавиши wasd, летая камерой в пространстве. Это удобно. Если вы работаете в UE4. В юнити из версии в версию сохраняется непонятный баг, когда, подлетая к требуемому объекту, камера внезапно отлетает на многие километры от объекта, и приходится заново к нему приближаться. В твиттере мне говорили, что это нормально, что юнити не иногда не угадывает с масштабом сцены, но левелдизайнеру это почему-то не кажется нормальным. 

Вот на таком компьютере вылеты юнити – это нормально. 

1

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

Элементарная задача. Есть прямоугольная стена. Левелдизайнер придумал выпилить дырку в ней. В юнити вы не сможете этого сделать. В UE4 – красиво и элегантно. Вообще, в юнити из коробки работа с вершинами отсутствует, нужно допокупать какой-нибудь ProGrid. 

MonoDevelop. 

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

Конечно, скоро будет Unity 5. Но, боюсь, что к тому времени, когда баги нового юнити будут пофикшены до той степени, что можно будет относительно хорошо работать, я буду уже с UE4. 

Просто картинка

Чтобы не простаивало, пока я заработался.

room2

Еще немного о The Talos Principle

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

В The Talos Principle игрок попадает в такую ситуацию где-то после трети игры. Игра услужливо предлагает зажать спецкнопку, чтобы сделать уровню резет, это порадовало. Но спустя несколько уровней я вновь попал в такую ситуацию. И в этот раз подсказки не было. Попал я в эту ситуацию специально, прекрасно зная, что, перекинув кубик через стену, я никак не смогу его принести назад. Но игра никак на это не отреагировала. Не предложила зажимать спецкнопку. И это не очень хорошо – игрок может и не вспомнить, что зажимать нужно было именно Y на геймпаде. Если, конечно, он вообще поймет, что уровень нужно было сбросить.

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

Конечно, если игра именно об обмане, если игра именно о безвыходных ситуациях (идея: игра, где цель – загонять себя в абсолютно безвыходные ситуации), все эти советы ни к чему.