Сообщение от Mr_F_
я не говорю про однотипную работу, скорее наоборот про разнотипную.
чтобы сделать хорошее демо, тебе надо сделать максимум важного и минимум неважного. т.е. вот так: http://ru.wikipedia.org/wiki/%D0%97%...B5%D1%82%D0%BE
Если ты делаешь однотипную работу, то скорее ты где-то пошёл не в ту сторону. Собственно, имхо, для реализации какого угодно проекта в первую очередь необходимо выделить самое главное, без чего проекта не будет, а из него ещё самое главное и т. п. Игра не загнется от того, что ты не расставил фонарные столбы по всей локации, от того что у тебя UV кривые на мусорном бачке, от того что ты сделал 3 квеста вместо 100. Главное реализовать самую самую суть. Это единственный вариант, если ты хочешь что-то успеть.
В данном случае переход к командной разработке (больше чем из 3 человек твоих друзей) ничего лучше не сделает. Если ты САМ не можешь сделать игру и не представляешь как (даже если бы это заняло очень много времени), то и других ты правильно не скоординируешь, будет у тебя команда настраивать UV на мусорных бачках, а игра от этого лучше не становиться. Если ты САМ способен сделать рабочее демо, и сделал его, то ты знаешь подводные камни, ты знаешь что удачно играется/легко делается, а что неудачно/сложно, ты знаешь в каких местах очень нужна хорошая медия, а в каких можно обойтись подешевле.
Если ты начнёшь с команды, имхо, это будет способствовать тому, что
- каждый будет делать свою игру и считать что он самый правый
- каждый будет более расслаблен, свалив часть ответственности на другого
Повторюсь, если речь идёт о команде аля я и пара моих друзей, то результат и правда может быть гораздо лучше - вас будет достаточно мало для сохранения индивидуальной ответсвенности, и вы все будете проникнуты идеей. |
Да, только я локализовал конкретную проблему, а ты опять всё обобщил и выдал общие рекомендации.
Однотипная работа в моём понимании такая, которую по прежнему нельзя сделать продвинутым интеллектуальным инструментарием, но всё же при выполнении которой ощущаешь монотонность своих действий. Её надо сводить к минимуму, но практика показывает, что её по прежнему остаётся очень много, даже в небольших проектах.
Далее давай тогда разделять демо и готовый проект, возможно от стадии 9 сначала надо перейти к стадии демо, а потом уже к полноценному проекту, но от последнего всё равно не уйти, а значит и однотипную работу надо выполнить. Следовательно можно согласиться что до стадии демо по прежнему выгодней работать одному, исключая однотипную объемную работу, и сосредоточить внимание на сути демы. Но далее, нужно что-то предпринимать, если проект большой - в одиночку ты затратишь неоправданно много времени. Согласен что в случае наличия демы у тебя вообще будет больше шансов собрать команду.
Далее "уметь" и "знать" не одно и тоже - ты можешь быть уверен что сделаешь проект один, но наперед не знаешь в деталях какие трудности будут возникать. Поэтому нужно создавать команду когда ты знаешь что сам сможешь заменить любого участника, но всё таки уметь отдавать большую часть работы при этом контролируя общий процесс. Несомненно здесь самую важную роль играет правильная и конкретная постановка задачи каждому участнику команды - иначе будут возникать описанные тобой ситуации, когда участники начинают додумывать за автора, возникают конфликтные ситуации и в условиях неопределённости людям уже не хочется ничего делать.
Например мне несколько людей предлагали помощь в написании движка, однако из-за того что вся работа была взаимосвязана и изначально предполагала участие одного программиста-автора, я не смог найти изолированной части, которую можно было бы отдать другому человеку, так чтобы ему не пришлось вникать во все детали движка (при этом архитектура как раз была продумана и предполагала более простое и монолитное решение для лучшей производительности). Несмотря на то что я уверен в своих знаниях и когда-нибудь доделаю движок, наличие команды, которая была бы в курсе происходящего, сильно ускорило бы разработку. Пока же мне остается контролировать общий объем кода, чтобы оперативно вносить изменения и улучшения, жертвуя при этом разносторонностью движка. Например в случае наличия команды, было бы неплохо поэкспериментировать с разными гапи, а так как я один, такие эксперименты подпадают как раз под категорию "ненужного/неважного" для реализации демоверсии.