При разработке больших и серьёзных игр есть много вещей, которые желательно знать ещё на препродакшене.
Когда игра разрабатывается маленькая, да ещё и без отрыва от основной работы, фактически, есть лишь одна необходимая ещё до начала разработки вещь:
1) Vision
То есть хотя бы один человек в команде должен понимать, какую игру он хочет получить в итоге и чем она будет ему интересна.
Фактически, в своём воображении он уже должен вовсю проходить её раз за разом и вычищать баги игропроцесса.
Так же очень желательно, чтобы этот человек мог объяснить vision остальной команде.
Совершенно не обязательно, чтобы этот vision был в той или иной форме записан в концепт документе (команда-то маленькая, всем и так легко объяснить) но это может хорошо помочь.
Остальное уже не обязательно, но желательно. Итак, в порядке от более важных и по нисходящей:
2) Прикидка сроков
Поначалу кажется, чем более "независима" разработка, тем меньше нужны вообще какие-либо сроки.
Но это не правда.
Какие-то временные рамки желательно задать с самого начала, иначе есть риск затянуть проект до такой степени, что его всем просто надоест переделывать.
Мы выбрали в роли такого срока - два месяца. (В самом крайнем случае - плюс ещё неделя.) Если за это время проект не будет закончен (т.е. новые фичи будут всё ещё добавляться, новый арт всё ещё рисоваться, а билды ещё не будут отправлены на продажу/издателям), я, например, из команды выйду, на какой бы стадии дело не находилось (даже если будет "ещё чуть-чуть").
Так же очень желательно задать определённые дедлайны, на которых бы можно было оценить, есть ли смысл ещё рыпаться, или уже пора прикрывать лавочку.
В "маленькой" разработке я вижу два таких основных дедлайна:
Первый, когда доделан инструментарий игры, и все изменения можно сразу же (или после компиляции) увидеть в игре.
Второй, когда прекращено добавление новых фичей.
У нас эти дедлайны выставлены на месяц и на два, соответственно.
3) Прикидка объема работ
Практически все выходящие казуальные игры более или менее основаны на каких-то других, уже вышедших ранее казуальных играх (новички старательно пытаются избежать этой "участи" но я лично ничего плохого в этом не вижу, кроме совсем уж отпетых случаев плагиата).
Кроме всего прочего, этот факт позволяет взять ближайшую игру-конкурента (в нашем случае - Virtual Villagers), распотрошить её на предмет нахождения ресурсов (очень часто они лежат открыто или почти открыто).
Арт показывается художнику, сама игра - программисту и спрашивается, сколько времени им понадобилось бы на написание точно такой же игры (рисование точно таких же картинок, плюс может половину переделывать придётся)? Ну, то есть вот, если бы это они её разрабатывали.
После чего больший из этих сроков берётся и умножается в три раза. Если программист говорит, что собирается делать игру на новом движке - полученный срок можно ещё раз умножить вдвое. Это, значит, и есть время на работу.
Отдельно и подробно обсуждаются все вопросы, которые кажутся затруднительными или вызывают хоть малейшее недоумение хоть одного человека в команде.
Бывает очень неплохо хотя бы в общих чертах придумать и расписать панели игры (как минимум - они могут послужить основой недо-диздока, которым всё равно рано или поздно придётся заняться).
4) Прикидка трат
В шароварной игре (а я всё это время говорю о шароварных казуалках) траты скорее всего не окупятся до самой отправки игры в продажу. Так что, если в команде нет художника (а два человека - дизайнер и программист, тут оптимальная команда) значит изначально придется всё делать на графике любой игры-конкурента (либо на кривых зарисовках дизайнера в пайнтбраше), а потом заказывать перерисовку всей графики где-то на аутсорсе. Если в команде нет музыканта - тоже самое, но со звуком и музыкой. В любом случае, желательно узнать примерные расценки на нужный объём работ, а так же морально решиться выкинуть эту сумму в трубу, если игра не продастся, или вообще не выйдет.
Да. Не просто решение, но значительно приятнее принимать его раньше, нежели позже.
5) Прикидка окупаемости
Если в команде есть человек, хоть немного разбирающийся в рынке, он может сам сделать некие примерные прикидки, что будет, если игра на Реал, представим, не попадёт и вообще пройдёт мимо большинства топов, но всё же получится неплохой.
Если такого человека нет, ничего не мешает вам связаться с ближайшими конкурентами (возможно и теми, чью графику и дизайн вы собираетесь вовсю использовать при разработке) по ICQ, или встретиться с ними на конференции и аккуратно расспросить в общих чертах, сколько нулей перед значком доллара было в той сумме, что они получили за свою игру в первые несколько месяцев.
Либо можно поступить аккуратнее: Спросить сколько они делали игру, сколько проектов делали в то время, и окупилась ли она за первые месяцы (а если не окупилась - то очень ли сильно в убытке они остались?), а потом посмотреть, сколько человек её делало, сравнить со своими показателями и прикинуть.
Если есть все пять этих вещей - за «маленький» проект можно смело браться (но конечно, это не является гарантией того, что удастся его закончить)
Юридическая сторона
[Print]
Гость