Комментарий ментора по первой попытке:
1) стр 82 и 23 - магические числа
2) следует разделять ответственности, не засовывайте всю логику в один класс, вынесите логику применения силы, а также логику создания как в фабричных паттернах, в отдельные классы Exploader и Spawner, и эти компоненты должны быть не обязательно на кубах, можно и следует их держать отдельно от кубов
Моё мнение по каждому пункту:
1) После долгого перерыва забыл, что нужно перепроверять код на магические числа, исправил быстро
2) У меня изначально получился небольшой класс в котором было всего два метода собственно спавн мини кубиков и взрыв и я подумал что не стоит его дробить на столько чтобы в каждом компоненте было по одному методу, но оказывается стоило
Код второй попытки: https://github.com/NoNameDeleted/CubesExplosion/tree/4596e4cffe8bad91549bb6daa86605455b2fc71b
Комментарий ментора по второй попытке:
Доработать
1. newObject.GetComponent<Renderer>() - один объект не знает, какие могут быть компоненты у другого. Стоит или проверить наличие, или пусть второй сам найдет и сохранит у себя. А дальше или сам делает нужные действия с компонентом, или вернет его по запросу.
2. Instantiate(template - создавайте не по GameObject, а сразу по нужному компоненту и обращайтесь к его новому методу Init, чтобы задать все нужные данные.
3. for (int i = 0; i < UnityEngine.Random.Range(minCubeParts, maxCubeParts + 1); i++) - некорректное использование Random.Range - на каждой новой итерации цикла будет получено новое число. Сначала получите число в переменную и уже используйте переменную.
Мой мысли:
1 и 2) Это тот самый знаменитый паттерн "фабрика" котрый я честно пытался загуглить и понять, но в инете какая-то супер сложная схема и мутные непонятные примеры. Так что ментору пришлось напрямую говорить мне что и как написать. В этом наверное и есть его задача и теперь я понял как это работает. Всё равно бы я сам не додумался что можно сделать метод Init в самом кубе чтобы он как бы сам себя задавал параметры - меньший размер и рандомный цвет. И ещё я думал что GameObject.Instantiate работает только с самим GameObjecт'ом и даже не думал, что можно с помощью этого метода создавать объект любого класса например Cube в моём случае. В такие моменты вспоминаю о том как же всё таки хорошо что я учусь не сам, а с ментором))
3) Эту ошибку с рандомом я даже не заметил, потому что даже в таком неверном виде технически она работала правильно и спавнила от 2 до 6 кубов как и должна. Это скорее просто невнимательность связанная с долгим перерывом на два месяца.
И финальная попытка которую приняли с небольшими замечаниями: https://github.com/NoNameDeleted/CubesExplosion
Комментарий ментора:
1) шанс деления куба следует хранить в классе Cube, спавнер должен только создавать
2) даже развёрнутым свойствам следует устанавливать приватный set, все изменения данных следует проводить в методах
Моё мнение:
1) Это скорее стилистическое субъективное замечание
2) А вот про это я не совсем понял, ведь если всем свойствам ставить приватный set, то по сути их вообще нельзя менять извне, но это как то бессмысленно зачем они тогда вообще нужны можно тогда просто писать геттеры и сеттеры для каждого свойства и это же кринж (кто делал игры в Gdevelop поймут о чём я🙃) может быть он имел ввиду конкретно мой случай, а не вобщем, но всё равно странно. Есть же даже отдельное понятие как "контрактное программирование" акцент в котором как раз делается на проверки передаваемых значений через контракты (проверки) в публичных сеттерах у свойств, ну да ладно