Я просто пытаюсь сказать что сериализация и перерисовка инспектора (и прочих окон) Юнити уже избитая тема. Есть готовые хорошие решения.
Когда несколько лет назад «вкатывался» в Юнити тоже считал что надо знать основы, своё это надежнее и т.д. Когда вкатился понял что есть экономика из серии, взять 5 платных плагинов из которых 4 не подойдут, а 1 надо будет допилить. На его допилку, как и было сказано в вашей статье, конечно нужны какие никакие знания, но это всё равно будет быстрее чем писать всё с нуля.
Так вот к экономике 5 плагинов по 40$ в среднем, ну и на допилку максимум 3 дня. Писать тулзу с нуля это до 2 недель (подчеркиваю ДО, можно и за пол часа). По чаще всего пишут тулзу по потребности и пока ее делают дизайнеры сидят и неспешно ковыряют другие задачи палкой.
Это относиться ко многим вещам в Юнити, и интерфейс, и работа со звуком, и с погодой и навмешем… Все они в стандартном варианте часто не дают требуемых стандартов, все их можно имея время и мозги допилить до нужного уровня, НО это время. Либо обмазываемся плагинами, теряем деньги, экономим время… Если это не домашний хобби проект, то на практике чаще всего с коллегами склоняемся к первому варианту.
Повторю этот опыт пришел ко мне горьким опытом проваленных сроков.
Интересно кто ЦА?
Прогерам это не сильно надо, их все в коде.
Если делать инструменты для геймдизов, то есть 1001 и одно шикарных решений (напр. Один).
То есть это только для тех кто собирается писать свой инструмент для написания инструментов, но тогда материала очень мало.
ОФФТОП: А вообще не знаю, мне кажеться что время писать и моделить все с нуля на Unity подходит к концу. Правило хорошего тона, брать готовые ассеты и на их основе уже делать проект/прототип.
Часто думал об этом и полностью согласен. Практически в любом вопросе с руководством начиная с вопроса сделать кондиционер попрохладнее или повысить зарплату, всегда нужно быть готовым услышать «не нравиться увольняйся», и если эту карту крыть нечем (нет ни job offer-а, ни подушки безопасности), то уже тем более доказывать что-то там о ведении дел или свою правоту смысла нет.
Поэтому только будучи уверенным что без этой работы я через 3 месяца не окажусь на теплотрассе, я начинаю высказывать свою мнение, пробовать новые инструменты и т.д. Не знаю это реалии постсовка или просто индивидуальный жизненный опыт.
Ну вроде как «Шпиль», сама игра платная, и каких-то трудностей в получении карт не замечено. То есть имеем хорошую карточную игру без имбовых карт и без доната. Другое дело то что эта игра не подходит под определение «игры-сервиса», но это уже совсем другая история )
Дисбалансные карты. Которые просто must have, и само собой это оранжевые (легендарные) карты. Что приводит нас к еще одной интересной теме по дэк билдингу. Должны ли «платные/дорогие/редкие» карты быть ключом к победе? Если да, то насколько дорого и долго можно мучать игрока перед их получением, если нет, то как тогда монетизировать игру?
Здесь больше об обучении игрока.
Если же более практические советы, то хотелось бы добавить про «нижний» дисбаланс — ненужные карты, плохо, но не смертельно и «верхний» дисбаланс — карта которая так мощна, что может сделать ненужными целые колоды. Вот это уже может быть приговором для игры. Как пример отличной задумки, но убитой верхним дисбалансом игры — Duelyst.
Книгу наверное надо было назвать «для любителей поиска баланса в геймдеве».
Усиленно скролил вниз чтобы посмотреть как реализована загрузка из Google doc-ов в Unity.
Я знаю только способ ручной загрузки в editore и созданием на их основе скриптов-словарей со значениями. Жаль что не увидел тут иной способ.
Как я понял в любом случае у нас идет обращение к инстансу, то есть реализуется сингтон, то есть смысл ивентов теряется напрочь. Что мешает отправлять обычные функции в этот инстанс (антипаттерн мега-класс), зато соблюдается инкапсулирование.
Оценка тестовых заданий это всегда очень субъективно. Был недавно один опыт. Дали задание, сказали что требуется. (Прим. Простенькая аркада на Unity для программиста) Сказано сделано. Потом пришло ревью — «Мы вам отказали так вы использовали новую версию ПО, а она нестабильна надо было делать на старой. А еще кое где в коде нам показалось что вы скопипастили. И программа пару раз нам выдала рекомендации по исправлению, мы их даже не смотрели, но считаем что это плохо.» И вишенка на торте — «А еще у вас дизайн UI грубоват». И это на вакансию программиста. Признаться для себя решил что с тестовыми заданиями с меня хватит, лучше потратить пару недель выложить хороший продукт с открытым кодом и не «грубым» UI и всех отправлять к нему по ссылке.
Как популистика пойдет, как деловая литература нет.
1. Обязанность менеджера не в принятии решений, а в организации принятия решений. Он не просто должен говорить «да» «нет», но и наладить алгоритм по каким вопросам к нему приходят, и как дальше поступают если его нет.
2. «Недолго посовещавшись, решили, что хрупкая маленькая девушка не справится и отдали стикер самому здоровенному мужику»… дальше читать не стал это вообще бред, давайте отдадим заполнение новостей самому быстропечатающему, мыть туалет самой хозяйственной, купить коврик тому кто знает ближайшие рынки… и в чем игра? Банально вернулись к тому с чего начали.
На моей практике, достаточно часто получалось так, что при вызове строковой перегрузки StopCoroutine не происходило ровным счетом ничего. Корутина продолжала выполняться.
На самом деле совпадение что оно вообще иногда останавливалось. Строковая строка вовсе не обязательно обращается к тому же корутину что был начат.
У меня два вопроса:
1. Есть где либо пример кода этой книге в скачиваемом виде? Обычно это идет к книгам по программированию и всегда к обучающим материалам по Unity.
2. Не получится ли материал быстро устаревающим с учетом всего того что нам готовит Unity.2019?
В целом с автором полностью согласен. Так был и на стороне внедренцев и на стороне заказчика. И позиция многих внедренцев это сразу же при неудобных вопросах вставать в позу «мне такие данные дали», «а мне такую форму отдел продаж утвердил» и т.д.
Думаю надо вернутся к принципу «хороший внедренец тот которого нет», и на практике часто прихожу к тому что вместо 1000 строк кода новой конфигурации иногда просто надо поставить в одном из цехов промышленные весы.
Как мне показалось проблема очевидна: «Бюрократия умрет с последним человеком».
Ну а если серьезно то со стороны выглядит что дружный коллектив решает проблему эффективнее Scrum методик. Но тогда интересно было бы внести эту плоскость и рассмотреть такой вариант: Дружный коллектив + Без Scrum VS Недружный коллектив / C идеальным Scrum
Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — общий интерес компании, не только ваш).
Если немного переформулировать в наши реальности то получается:
«Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — интерес компании, а не ваш).»
Так как в статье не увидел связи результата проекта с личными интересами остальных лиц (ПМ и специалистов).
А если начать именно с этого «Совместить интерес компании с личными интересами работников», то тогда работник и без напоминания готов будет не то что задержаться, а жить на работе.
Сам удаленщик и по утрам тоже дико бешусь что приходится пить купленный за свои деньги кофе, хоте те кто поедут в офис будут пить его там бесплатно!
Когда несколько лет назад «вкатывался» в Юнити тоже считал что надо знать основы, своё это надежнее и т.д. Когда вкатился понял что есть экономика из серии, взять 5 платных плагинов из которых 4 не подойдут, а 1 надо будет допилить. На его допилку, как и было сказано в вашей статье, конечно нужны какие никакие знания, но это всё равно будет быстрее чем писать всё с нуля.
Так вот к экономике 5 плагинов по 40$ в среднем, ну и на допилку максимум 3 дня. Писать тулзу с нуля это до 2 недель (подчеркиваю ДО, можно и за пол часа). По чаще всего пишут тулзу по потребности и пока ее делают дизайнеры сидят и неспешно ковыряют другие задачи палкой.
Это относиться ко многим вещам в Юнити, и интерфейс, и работа со звуком, и с погодой и навмешем… Все они в стандартном варианте часто не дают требуемых стандартов, все их можно имея время и мозги допилить до нужного уровня, НО это время. Либо обмазываемся плагинами, теряем деньги, экономим время… Если это не домашний хобби проект, то на практике чаще всего с коллегами склоняемся к первому варианту.
Повторю этот опыт пришел ко мне горьким опытом проваленных сроков.
Прогерам это не сильно надо, их все в коде.
Если делать инструменты для геймдизов, то есть 1001 и одно шикарных решений (напр. Один).
То есть это только для тех кто собирается писать свой инструмент для написания инструментов, но тогда материала очень мало.
ОФФТОП: А вообще не знаю, мне кажеться что время писать и моделить все с нуля на Unity подходит к концу. Правило хорошего тона, брать готовые ассеты и на их основе уже делать проект/прототип.
Поэтому только будучи уверенным что без этой работы я через 3 месяца не окажусь на теплотрассе, я начинаю высказывать свою мнение, пробовать новые инструменты и т.д. Не знаю это реалии постсовка или просто индивидуальный жизненный опыт.
Если же более практические советы, то хотелось бы добавить про «нижний» дисбаланс — ненужные карты, плохо, но не смертельно и «верхний» дисбаланс — карта которая так мощна, что может сделать ненужными целые колоды. Вот это уже может быть приговором для игры. Как пример отличной задумки, но убитой верхним дисбалансом игры — Duelyst.
Усиленно скролил вниз чтобы посмотреть как реализована загрузка из Google doc-ов в Unity.
Я знаю только способ ручной загрузки в editore и созданием на их основе скриптов-словарей со значениями. Жаль что не увидел тут иной способ.
1. Обязанность менеджера не в принятии решений, а в организации принятия решений. Он не просто должен говорить «да» «нет», но и наладить алгоритм по каким вопросам к нему приходят, и как дальше поступают если его нет.
2. «Недолго посовещавшись, решили, что хрупкая маленькая девушка не справится и отдали стикер самому здоровенному мужику»… дальше читать не стал это вообще бред, давайте отдадим заполнение новостей самому быстропечатающему, мыть туалет самой хозяйственной, купить коврик тому кто знает ближайшие рынки… и в чем игра? Банально вернулись к тому с чего начали.
На самом деле совпадение что оно вообще иногда останавливалось. Строковая строка вовсе не обязательно обращается к тому же корутину что был начат.
1. Есть где либо пример кода этой книге в скачиваемом виде? Обычно это идет к книгам по программированию и всегда к обучающим материалам по Unity.
2. Не получится ли материал быстро устаревающим с учетом всего того что нам готовит Unity.2019?
Думаю надо вернутся к принципу «хороший внедренец тот которого нет», и на практике часто прихожу к тому что вместо 1000 строк кода новой конфигурации иногда просто надо поставить в одном из цехов промышленные весы.
Ну а если серьезно то со стороны выглядит что дружный коллектив решает проблему эффективнее Scrum методик. Но тогда интересно было бы внести эту плоскость и рассмотреть такой вариант: Дружный коллектив + Без Scrum VS Недружный коллектив / C идеальным Scrum
Если немного переформулировать в наши реальности то получается:
«Если потребуется специалист должен быть готов задержаться на работе (так как завершение и успешная сдача проекта — интерес компании, а не ваш).»
Так как в статье не увидел связи результата проекта с личными интересами остальных лиц (ПМ и специалистов).
А если начать именно с этого «Совместить интерес компании с личными интересами работников», то тогда работник и без напоминания готов будет не то что задержаться, а жить на работе.
Можно даже в будущем ее расширить и глубже в плане психологии, и шире в плане иных аспектов жизни.