ПРАКТИЧЕСКАЯ ЧАСТЬ 🧑💻
Всем привет) Зафиналиваю рассказ об интенсиве, и наконец настала очередь практики. Собсна, “Какое было задание?”. Задание дал по харду: “Написать расширение, помогающее левелдизайнеру строить уровни”. Давайте закину вам ТЗ, может кто-то захочет повторить))
1. Размещаемые объекты должны быть префабами для удобства настройки геймплея;
2. Префабы должны браться из сгенерированной папки, куда разработчик поместит префаб после его настройки;
3. В расширении префабы выводятся в сетку, которая должна подстраиваться под размер окна;
4. У каждого элемента должна быть превьюшка, но сделанная не вручную;
5. Все префабы должны быть разделены на каталоги, по типу "постройка", "окружение" и тд;
6. При помощи клавиатуры добавить возможность поворота;
7. При активации кнопки постройки и перемещении указателя на сцену должно появиться превью постройки;
8. Постройки не должны ставиться одну в другую.
Звучит сложно, но до этого на теории мы разобрали всю базу для этого, включая работу с файлами и всеми элементами GUILayour.
А зачем вообще упоролись в практику, ведь могли за 2 дня еще чо-нить разобрать? Странный вопрос (я сам его придумал) думаю итак все понимаете на*уя нужна практика. Но все-таки, я очень хотел, чтобы все участники:
А) Закрепили пройденный материал;
Б) Погрузились в реальный небольшой спринт и поняли, как это работает в реальности;
В) Научились работать в команде и распределять задачи.
Ну и да, все получилось. Распределили команды +- равномерно по опыту разрабов, каждый прочувствовал на себе, что такое спринт и как это выматывает, когда до дедлайна час. Особенно порадовало как ребята адекватно раскидали таски между собой без прожект манагеров))
А результат вы уже видели в прошлом посте, и если хотите увидеть разбор кода, то накидайте реакций, и будем долбить дальше 🔥
Всем привет) Зафиналиваю рассказ об интенсиве, и наконец настала очередь практики. Собсна, “Какое было задание?”. Задание дал по харду: “Написать расширение, помогающее левелдизайнеру строить уровни”. Давайте закину вам ТЗ, может кто-то захочет повторить))
1. Размещаемые объекты должны быть префабами для удобства настройки геймплея;
2. Префабы должны браться из сгенерированной папки, куда разработчик поместит префаб после его настройки;
3. В расширении префабы выводятся в сетку, которая должна подстраиваться под размер окна;
4. У каждого элемента должна быть превьюшка, но сделанная не вручную;
5. Все префабы должны быть разделены на каталоги, по типу "постройка", "окружение" и тд;
6. При помощи клавиатуры добавить возможность поворота;
7. При активации кнопки постройки и перемещении указателя на сцену должно появиться превью постройки;
8. Постройки не должны ставиться одну в другую.
Звучит сложно, но до этого на теории мы разобрали всю базу для этого, включая работу с файлами и всеми элементами GUILayour.
А зачем вообще упоролись в практику, ведь могли за 2 дня еще чо-нить разобрать? Странный вопрос (я сам его придумал) думаю итак все понимаете на*уя нужна практика. Но все-таки, я очень хотел, чтобы все участники:
А) Закрепили пройденный материал;
Б) Погрузились в реальный небольшой спринт и поняли, как это работает в реальности;
В) Научились работать в команде и распределять задачи.
Ну и да, все получилось. Распределили команды +- равномерно по опыту разрабов, каждый прочувствовал на себе, что такое спринт и как это выматывает, когда до дедлайна час. Особенно порадовало как ребята адекватно раскидали таски между собой без прожект манагеров))
А результат вы уже видели в прошлом посте, и если хотите увидеть разбор кода, то накидайте реакций, и будем долбить дальше 🔥
🔥37👍3⚡2🤡1
Привет, котаны)
Я сел заниматься разбором LevelBuilder и встал в небольшой тупик. Скрипт вышел под 300 строк, что для расширений так-то адекватно, но есть где сократить. В одном посте все не поместится, и мне кажется, что лучше сделать серию постов по самым горячим темам.
👇 Ниже скину опрос)
Я сел заниматься разбором LevelBuilder и встал в небольшой тупик. Скрипт вышел под 300 строк, что для расширений так-то адекватно, но есть где сократить. В одном посте все не поместится, и мне кажется, что лучше сделать серию постов по самым горячим темам.
👇 Ниже скину опрос)
👍11🔥5👌2
Собственно, к чему я это всё? Мне нужна ваша помощь: какую тему вы хотите видеть в разборе больше всего?
Напишите в комментах свои пожелания, и уже завтра я выкачу первый пост, который выберете вы :3
Напишите в комментах свои пожелания, и уже завтра я выкачу первый пост, который выберете вы :3
Anonymous Poll
27%
Разбор механик расширения
22%
Рефакторинг кода для сокращения размера
30%
Интересные приемы из кода
18%
Разбор ошибок и возможных улучшений
2%
Версия в комментах
👍7🔥5👌1
РАЗБОР ВВОДА В РАСШИРЕНИЯХ
Спасибо за участие и комменты в опросе :3 Как и обещал, закидываю пост)
Во время практики ребятам нужно было сделать управление размером/поворотом объекта при помощи нажатия клавиш. Вроде все изи, но есть нюанс: ввод, который мы используем в плеймоде, отличается от ввода в редакторе.
Ситуация такая, класс Input для редактора недоступен, но есть класс Event с информацией о пользовательском вводе или рендеринге окна. Для каждого вызова OnGUI в скриптах создается новый Event, т.е. каждый метод отрисовки в редакторе может создать новый Event и значит их может быть несколько.
Остается вопрос: как мне определить нужное событие и вычленить из него нажатие клавиши?
Я смотрю на статическое свойство current, содержащее в себе Event. Он обрабатывается прямо сейчас в том скрипте, где я обращаюсь к этому свойству. И при помощи поля type я определяю, что за событие сейчас происходит, и провожу сравнение с желаемым событием из EventType.
После проверки события дело остаётся за малым, я уже знаю, что тип события - это нажатие на клавишу, а значит, могу обратиться к полю keyCode, которое хранит код нажатой клавиши, и среагировать соответствующим образом.
Такие дела, накидывайте 🔥, если вам заходит такой формат)
Спасибо за участие и комменты в опросе :3 Как и обещал, закидываю пост)
Во время практики ребятам нужно было сделать управление размером/поворотом объекта при помощи нажатия клавиш. Вроде все изи, но есть нюанс: ввод, который мы используем в плеймоде, отличается от ввода в редакторе.
Ситуация такая, класс Input для редактора недоступен, но есть класс Event с информацией о пользовательском вводе или рендеринге окна. Для каждого вызова OnGUI в скриптах создается новый Event, т.е. каждый метод отрисовки в редакторе может создать новый Event и значит их может быть несколько.
Остается вопрос: как мне определить нужное событие и вычленить из него нажатие клавиши?
Я смотрю на статическое свойство current, содержащее в себе Event. Он обрабатывается прямо сейчас в том скрипте, где я обращаюсь к этому свойству. И при помощи поля type я определяю, что за событие сейчас происходит, и провожу сравнение с желаемым событием из EventType.
После проверки события дело остаётся за малым, я уже знаю, что тип события - это нажатие на клавишу, а значит, могу обратиться к полю keyCode, которое хранит код нажатой клавиши, и среагировать соответствующим образом.
Такие дела, накидывайте 🔥, если вам заходит такой формат)
🔥31⚡2👍2❤1🍓1
С превью префаба можно работать!
На практике вебинара мы дали ребятам задание отобразить все префабы в каталоге. Если для каждого элемента делать отдельную иконку, - это ад, а расширение каталога занимает больше времени специалиста.
На самом деле для этой задачи у меня есть элегантное решение. Вы заметили, что Unity для префабов генерирует специальную иконку предпросмотра, которой мы будем пользоваться.
В Unity есть фишка - AssetPreview. Очень удобный класс, с которым мы получим превьюшку объекта, если у нас есть ссылка на него.
На практике мы пробегались по всему каталогу и получали превьюшку типа Texture2D для каждого элемента. Дальше - во время создания грида в качестве контента мы передаем иконки, а не сами объекты. Так можно делать, ибо индекс иконки соответствует индексу объекта в каталоге.
Ну и, напоследок, хотелось бы поздравить всех с наступающим Новым годом) Желаю вам всем в новом году крутых райзов, интересных задач и бенчёвых проектов! 🎄
На практике вебинара мы дали ребятам задание отобразить все префабы в каталоге. Если для каждого элемента делать отдельную иконку, - это ад, а расширение каталога занимает больше времени специалиста.
На самом деле для этой задачи у меня есть элегантное решение. Вы заметили, что Unity для префабов генерирует специальную иконку предпросмотра, которой мы будем пользоваться.
В Unity есть фишка - AssetPreview. Очень удобный класс, с которым мы получим превьюшку объекта, если у нас есть ссылка на него.
На практике мы пробегались по всему каталогу и получали превьюшку типа Texture2D для каждого элемента. Дальше - во время создания грида в качестве контента мы передаем иконки, а не сами объекты. Так можно делать, ибо индекс иконки соответствует индексу объекта в каталоге.
Ну и, напоследок, хотелось бы поздравить всех с наступающим Новым годом) Желаю вам всем в новом году крутых райзов, интересных задач и бенчёвых проектов! 🎄
🎄22👍8🔥3⚡1