Вот и мне непонятно. Не скажете, где говорится, что медиатор или что-то подобное плохо в коп? Мне таким образом стало куда удобней работать, чем в каждом компоненте заводить несколько ссылок на другие компоненты и вызывать getComponent() для получения каждого.
Компоненты какого-то сложного объекта в любом случае как-то должны общаться друг с другом. Поэтому не вижу проблемы добавления класса-посредника для конкретного типа объекта.
В случае посредников для объектов сцены, особенно если их разделять по подсистемам (гуи, звук), тоже не вижу проблем. Объектам сцены все равно как-то потребуется обращаться друг к другу.
Касательно Unity3d. В нем раньше было сделано так, что у компонента были ссылки на кучу других компонентов, которые он не использует, что приводит к ненужной связанности компонентов. И это скорее создавало проблемы разработчикам движка, а не разработчикам, которые пишут на движке.
И наоборот, если даже делать универсальное хранилище для характеристик объектов, то апи доступа к ним стоит сделать типизированным (не object GetPropertyByName, а int GetLivesCount).
Кстати, я делал аналогично для доступа к данным из аниматора в Mecanim. Становиться удобней работать.
public class AnimatorParams
{
private Animator _animator;
public float Speed
{
get { return _animator.GetFloat("Speed"); }
set { _animator.SetFloat("Speed", value); }
}
...
}
Для кругозора можно еще почитать про аспекты (ваши компоненты на них сильно похожи) и мультиагентное программирование.
Полезно конечно будет почитать. Но из того, что я сейчас прочитал про аспекты – не сказал бы, что мои компоненты на них похожи. Я так понял, что если какой-то общий функционал вынести в отдельный метод, и как-то организовать его вызов при выполнении любого метода в любом классе, к которому он привязан, то эта дополнительная привязанная функциональность и будет называться аспектом. Аспектно-ориентированное программирование на C#
Вам тоже спасибо за книгу! Хотя ранее она мне уже попадалась. Вот только времени почитать не нашлось.
Могу сказать только то же, что и в моем комменте выше.
Спасибо за ссылку на книгу! Надо будет глянуть, в том числе и другие ее части.
Правильнее было бы сказать, что я не встретил книги или публикации, где собраны воедино описания реализаций типовых игровых механик, таких как:
характеристики объектов;
баффы/дебаффы;
способности/заклинания;
организация процессов экипировки персонажа, изучения навыков, покупки, особенно в клиент-серверных играх;
система диалогов;
система квестов.
Пока что пролистал мельком книгу. Про КОП, FSM, Behavior Tree в ней написано. А вот про перечисленное выше я не увидел. Большинство книг по архитектуре игр обычно ориентированно скорее на создание архитектуры движка, чем самой игры.
Мне показалось, что «машина состояний» будет понятней большему числу читателей, чем «конечный автомат». Не все в институте учились, и не у всех была теория автоматов. Но вы правы, стоит упомянуть в статье про конечный автомат.
Я уточню, что не в области тестирования работаю.
Так что, я здесь многие вещи пишу с точки зрения программиста.
Если у соискателя на вакансию тестировщика базовые вещи вызывают такое количество затруднений, значит он не особо готовился.
Конкретно по Вашим вопросам – я ничего не скажу, т.к. не разбираюсь в данной области.
А так вполне могут быть и другие причины, часть из которых я и перечислил в первом посту.
Этому человеку придется владеть речью и формализовать свои мысли в той форме, в которой его поймут разработчики, ПМ и прочие. Это проблема, которую должно было решить среднее образование.
Имхо, этот уровень на порядок ниже, чем необходимый для прохождения собеседования.
И с каких это пор образование решает психологические проблемы?
Я согласен брать людей с другим набором знаний, но вот они не согласны работать на правах и зарплате стажера.
И скорее всего правильно делают. Вы им на данном этапе делаете встречное предложение платить соответствующую зарплату, если их знания окажутся выше ожидаемых вами, или выдавать им премию если на испытательном сроке от них будет пользы больше ожидаемой вами? Я ни разу не слышал подобного предложения, а хотелось бы.
Допустим в Вашем направлении стало неперспективно работать (направление устарело или зарплаты стали низкими). Но у вас есть неплохая финансовая подушка. Вы согласитесь устроиться джуниором на длительный срок в соседнем направлении, где немалая часть ваших знаний вполне актуальна, но вам скажут, что им чихать на ваш опыт в соседнем направлении?
Лично я – нет. Либо устроюсь временно и сбегу сразу, как найду компанию, где меня устроят условия работы. Хотят – пусть ищут дальше или набирут студентов, потратят года 3 на их обучение тому, что человек из соседней области за полгода освоит на том же уровне.
Скажу на примере программистов — senior в одной области примерно равен midle в той, с которой он не работал. Переобучиться под другую область программирования обычно не занимает слишком много времени. Так как хоть и технологии другие, многие вещи пересекаются, да и есть понимание, как надо работать, что от тебя хотят, как решать проблемы.
Что мешало освежить свои знания и навыки перед собеседованием?
Время, объем знаний, работа на которой приходится колбасить по 12 часов в сутки, пятеро детей :)
Освежите за недельку-две перед собеседованием все то, на что вы потратили десяток лет жизни. Кто знает, что собеседующему придет спросить в голову.
Соискатель, который доходит за полтора часа беседы до восьмого вопроса, – редкость, такого я возьму на работу юниором. Доходящий за то же время до 11 вопроса может быть принят на должность ведущего тестировщика, однако за 240 проведенных собеседований таких оказалось только 5 человек!
Может, я слишком требователен к ответам?
Скорее всего, вы просто давно или маловато были собеседуемым :)
Вы учитываете факторы ниже или ищете чуть ли не идеальных кандидатов?
• Человек может волноваться, особенно в условиях ограниченного времени.
• Человек может плохо владеть речью, плохо излагать свои мысли. Некоторые хорошо делают, но плохо объясняют.
• Области его и ваших знаний могут плохо пересекаться.
• Вы одни и те же вопросы постоянно спрашиваете, что означает, что вы их хорошо разобрали и хорошо помните данную часть предметной области, но это не значит, что другие сделали акцент на этом.
• Как давно человек работал с технологией, о которой вы его спрашиваете. Может он когда-то был в ней экспертом, но забыл ее, так как не приходилось ей пользоваться последние несколько лет.
Большинство это не учитывают, а потом ходят сказки о том, что пришел чувак с опытом 10 лет на собеседование, а его знания и на джуниора не тянут. Конечно, и такое бывает, но гораздо чаще бывает, что собеседующий не смог увидеть реальный уровень собеседуемого.
Ниже конечно, только мое мнение, но может и другие будут с ним согласны.
Попробуйте предложить собеседуемым выбирать – устно или письменно отвечать на вопросы. В случае письменного варианта предоставить им час-полтора времени без вашего присутствия, оставив возможность обратиться к вам в случае непонимания, о чем спрашивается в вопросе. А также в случае кандидатов с опытом, сначала задавать вопросы 7-11, потом 5-6, а потом остальные. 3-ий вопрос и из него вытекающее я бы вообще убрал или оставил на последок, т.к. только из кольи выбьете подобными вопросами.
Глядишь, и на поиск 5 человек на должность ведущего тестировщика, нужно будет опросить 50 человек, а не 240.
Компоненты какого-то сложного объекта в любом случае как-то должны общаться друг с другом. Поэтому не вижу проблемы добавления класса-посредника для конкретного типа объекта.
В случае посредников для объектов сцены, особенно если их разделять по подсистемам (гуи, звук), тоже не вижу проблем. Объектам сцены все равно как-то потребуется обращаться друг к другу.
Касательно Unity3d. В нем раньше было сделано так, что у компонента были ссылки на кучу других компонентов, которые он не использует, что приводит к ненужной связанности компонентов. И это скорее создавало проблемы разработчикам движка, а не разработчикам, которые пишут на движке.
Тут просто одно и то же название используется в разных контекстах. То, о чем вы говорите – скорее модулями правильней называть, а не компонентами.
https://ru.wikipedia.org/wiki/Модульность_(программирование)
Шаблоны игрового программирования.Компонент
Полезно конечно будет почитать. Но из того, что я сейчас прочитал про аспекты – не сказал бы, что мои компоненты на них похожи. Я так понял, что если какой-то общий функционал вынести в отдельный метод, и как-то организовать его вызов при выполнении любого метода в любом классе, к которому он привязан, то эта дополнительная привязанная функциональность и будет называться аспектом.
Аспектно-ориентированное программирование на C#
Могу сказать только то же, что и в моем комменте выше.
Правильнее было бы сказать, что я не встретил книги или публикации, где собраны воедино описания реализаций типовых игровых механик, таких как:
характеристики объектов;
баффы/дебаффы;
способности/заклинания;
организация процессов экипировки персонажа, изучения навыков, покупки, особенно в клиент-серверных играх;
система диалогов;
система квестов.
Пока что пролистал мельком книгу. Про КОП, FSM, Behavior Tree в ней написано. А вот про перечисленное выше я не увидел. Большинство книг по архитектуре игр обычно ориентированно скорее на создание архитектуры движка, чем самой игры.
Я уточню, что не в области тестирования работаю.
Так что, я здесь многие вещи пишу с точки зрения программиста.
Конкретно по Вашим вопросам – я ничего не скажу, т.к. не разбираюсь в данной области.
А так вполне могут быть и другие причины, часть из которых я и перечислил в первом посту.
Имхо, этот уровень на порядок ниже, чем необходимый для прохождения собеседования.
И с каких это пор образование решает психологические проблемы?
И скорее всего правильно делают. Вы им на данном этапе делаете встречное предложение платить соответствующую зарплату, если их знания окажутся выше ожидаемых вами, или выдавать им премию если на испытательном сроке от них будет пользы больше ожидаемой вами? Я ни разу не слышал подобного предложения, а хотелось бы.
Допустим в Вашем направлении стало неперспективно работать (направление устарело или зарплаты стали низкими). Но у вас есть неплохая финансовая подушка. Вы согласитесь устроиться джуниором на длительный срок в соседнем направлении, где немалая часть ваших знаний вполне актуальна, но вам скажут, что им чихать на ваш опыт в соседнем направлении?
Лично я – нет. Либо устроюсь временно и сбегу сразу, как найду компанию, где меня устроят условия работы. Хотят – пусть ищут дальше или набирут студентов, потратят года 3 на их обучение тому, что человек из соседней области за полгода освоит на том же уровне.
Скажу на примере программистов — senior в одной области примерно равен midle в той, с которой он не работал. Переобучиться под другую область программирования обычно не занимает слишком много времени. Так как хоть и технологии другие, многие вещи пересекаются, да и есть понимание, как надо работать, что от тебя хотят, как решать проблемы.
Время, объем знаний, работа на которой приходится колбасить по 12 часов в сутки, пятеро детей :)
Освежите за недельку-две перед собеседованием все то, на что вы потратили десяток лет жизни. Кто знает, что собеседующему придет спросить в голову.
Скорее всего, вы просто давно или маловато были собеседуемым :)
Вы учитываете факторы ниже или ищете чуть ли не идеальных кандидатов?
• Человек может волноваться, особенно в условиях ограниченного времени.
• Человек может плохо владеть речью, плохо излагать свои мысли. Некоторые хорошо делают, но плохо объясняют.
• Области его и ваших знаний могут плохо пересекаться.
• Вы одни и те же вопросы постоянно спрашиваете, что означает, что вы их хорошо разобрали и хорошо помните данную часть предметной области, но это не значит, что другие сделали акцент на этом.
• Как давно человек работал с технологией, о которой вы его спрашиваете. Может он когда-то был в ней экспертом, но забыл ее, так как не приходилось ей пользоваться последние несколько лет.
Большинство это не учитывают, а потом ходят сказки о том, что пришел чувак с опытом 10 лет на собеседование, а его знания и на джуниора не тянут. Конечно, и такое бывает, но гораздо чаще бывает, что собеседующий не смог увидеть реальный уровень собеседуемого.
Ниже конечно, только мое мнение, но может и другие будут с ним согласны.
Попробуйте предложить собеседуемым выбирать – устно или письменно отвечать на вопросы. В случае письменного варианта предоставить им час-полтора времени без вашего присутствия, оставив возможность обратиться к вам в случае непонимания, о чем спрашивается в вопросе. А также в случае кандидатов с опытом, сначала задавать вопросы 7-11, потом 5-6, а потом остальные. 3-ий вопрос и из него вытекающее я бы вообще убрал или оставил на последок, т.к. только из кольи выбьете подобными вопросами.
Глядишь, и на поиск 5 человек на должность ведущего тестировщика, нужно будет опросить 50 человек, а не 240.