Просмотр исходного текста страницы Средства обмена информацией на РИ

'''Автор''': Хыиуду<br />
''Доклад был прочитан на Комконе 14 марта 2014 года''<br />

Пассивные средства - личный контакт
Пассивные средства - мобильная связь
Пассивные средства - рации игрокам
Активные средства - аскольдокарты
Активные средства - музыкальный движок
Активные средства - флешбеки
Интерактивные средства - общий обзор
Интерактивные многофункциональные средства - с чего начать?
Интерактивные средства - связь
Мобильная связь
Мобильный интернет
Локальная сеть
WiFi
Радиоканал
Оптический сигнал
Bluetooth
Интерактивные средства - толстый и тонкий клиент
КПК - схема разработки программного продукта
1. Мастер создает модель мира
2. Мастер создает концепт
3. Мастер пишет правила
4. РМ разрабатывает бизнес-логику.
5. РМ разрабатывает техзадание
6. Программист создает объектную модель
7. Программист имплементирует бизнес-логику
8. Программист создает интерфейс
9. Тестирование
Взаимодействие с программистом - "индус"
Взаимодействие с программистом - архитектор системы
Взаимодействие с программистом - экстремал
Взаимодействие с программистом - оценка времени


==Введение==
На любой ролевой игре рано или поздно возникает ситуация, когда мастер хочет передать для игрока некоторую игротехническую информацию. Начиная от "Теперь ты все понял, Нео, ты - Избранный!", кончая "проходя через болото, вас укусило крокодилом, отнимите у себя один хит". Проблема в том, что к каждому Избранному своего мастера еще можно приставить, а к каждому крокодилу - уже затруднительно. Тут и приходят на помощь всевозможные средства и методы донесения такой информации до игрока, активно или не очень использующиеся для этого разными мастерами на разных играх. В этом докладе я рассмотрю где-то с десяток таких средств, останавливаясь на их плюсах и минусах и применимости в условиях той или иной ролевой игры.

Разнообразие подобных средств - не сказать, что поражает воображение, но все же немало. И средства эти можно классифицировать по разным признакам. В этом докладе я решил разделить средства на три класса по степени вовлеченности игрока в процесс получения информации, и выделить средства пассивные, средства активные и средства интерактивные.

==Пассивные средства==

Пассивные средства подразумевают, что игроку для получения информации не требуется выполнять никаких действий, либо надо выполнять какие-то совершенно неспецифические, интуитивно понятные действия, например, принять звонок/смс на мобильном телефоне. Активные средства подразумевают применение некоторого предмета, объекта, который хранит нужную информацию в себе, а в процессе взаимодействия с ним игрок эту информацию получает, классический пример - аскольдокарточка. Наконец, интерактивные - это такие же объекты, но имеющие внутри себя какую-то электронную начинку, позволяющую не только выдавать уже имеющуюся информацию, но и продуцировать новую по ходу игры.

===Пассивные средства - личный контакт===

Личный контакт - это самое древнее, самое простое и самое очевидное средство передачи информации. Надо игроку что-то передать - пришел мастер и сказал. Или игротехника прислал. Этот способ, на самом деле, имеет значительно больше плюсов, чем мы привыкли думать. А именно:

# Факт передачи и приема информации очевиден для мастера (т.е. он может точно знать, что конкретный Вася знает, что он теперь Избранный).
# Исключено искажение информации (если игрок чего-то не понял - он может переспросить)
# Есть возможность обратной связи (если у игрока есть еще какие-то вопросы - он может их задать)
# Контакт физический (что позволяет передать не только информацию, но и какой-нибудь физический объект, например, меч или амулет. Попробуйте тот же меч переслать через смс!)

Недостатков же у этого способа два - это время и еще раз время. Во-первых, время, которое теряет мастер/игротех, выпадая на это время из потока своих обязанностей, во-вторых, то же самое время, в течение которого игрок не получает информацию в силу того, что его еще не нашли. Например, на "Первой Эпохе" я по просьбе Боро четыре часа искал на полигоне Анжея, чтобы передать ему, что Боро просил его подойти и обсудить какой-то вопрос. А когда встретил, узнал, что за эти четыре часа Боро уже дважды успел с Анжеем встретиться и все с ним обговорить. Информация перестала быть актуальной еще до того, как была доставлена.

Этот метод замечательно апгрейдится, если использовать рации. Региональщик в своей локации гораздо скорее найдет нужного человека, чем случайный игротех, которому, во-первых, топать через полигон, а во-вторых, он может и не знать, как выглядит нужный ему игрок. Еще есть неплохой метод, который можно назвать "почтовый ящик" - он использовался на игре "Aliens: Underground" по очевидным причинам (полигон - сеть подземных каменоломен, никакая связь не работает, а перемещение физически затруднительно). Выглядело это так: в каждой локации есть своего рода почтовый ящик, куда игроки складывают записки с заявками мастерам. Приходит региональщик и первым делом лезет в почтовый ящик. Что может - разруливает сам, что не может - относит на мастерку.


===Пассивные средства - мобильная связь===
Тупо и просто - позвонить игроку или отправить ему смс. Плюс - мобильные телефоны сейчас есть у всех. Минус - не все его могут таскать с собой всю игру (особенно если на игре есть персонажи-суккубы с костюмами формата "Мне просто интересно, откуда ты его доставать будешь"), не у всех он выдержит несколько дней на природе без зарядки, да и в конце концов, игрок, роющийся в телефоне, выглядит вполне вписывающимся в игру по современности или техногенку, но абсолютно неуместно на фэнтези или историчке. Плюс - еще про некоторые проблемы, связанные с мобильной связью, будет сказано в третьей части, где речь про интерактивные средства.

===Пассивные средства - рации игрокам===
Собственно, все сказано в заголовке. Игрокам раздаются рации, они кладут рацию в карман, гарнитуру в ухо, прячут под волосами - и готовы впитывать высшую мудрость от мастера, можно сказать, напрямую. В частности, на игре "Хогвартские Сезоны: 15 лет спустя" именно такой метод и был применен - главзлодей нашел себе пятерых учеников, которым были розданы рации, в которые он периодически шипел: "Слушайте меня, ученики мои! Придите сегодня в полночь к Визжащей Хижине, я буду говорить с вами!". Вариант в принципе жизнеспособен, но имеет ряд вполне очевидных ограничений:
# Возможен только на игре с дружбомагией, где вам не придется опасаться, что злонамеренные игроки будут читерить, слушать мастерский канал, или тупо уедут после игры обратно куда-нибудь в Дальнее Кукуево, забыв отдать рацию мастерам.
# Всех таких игроков придется снабжать по мере надобности батарейками и учить пользоваться рациями, чтобы один человек, у которого в кармане зажало тангенту (о чем он, естественно, не подозревает), не обеспечивал всем остальным непрекращающийся шум в ушах.
# Даже если у вас все игроки - друзья, умницы, мегавнимательны и технические гении, это все равно не спасет, если их тупо МНОГО - вам не хватит либо раций, либо каналов на каждого. Нелицензируемых гражданских частот не так уж много, а байки про то, как мастера по незнанию или ошибке выходили, скажем, на милицейскую волну, не единичны ("Эй, у меня тут на перекрестке шесть трупов - нужны кому?" - "Сейчас приду, заберу, будут у нас дрова рубить").

==Активные средства==
===Активные средства - аскольдокарты===
Аскольдокарты (далее АК) - технология уже не новая, используется уже как минимум с 2006 года, и за это время уже успела попасть в поле зрения большей части игроков и мастеров Центрального региона. Если вы по какой-то причине все же не знакомы с ней - почитать можно здесь: http://rovenion.livejournal.com/712709.html

Модель АК обладает рядом существенных плюсов и некоторым количеством несомненных минусов. Плюсы:
# Модель никоим образом не требует вмешательства мастеров или игротехов.
# Модель легко интегрируется с любыми другими моделями, построенными по похожей технологии. Например, если у вас есть в игре медицина-на-АК и алхимия не на АК, ничего не мешает вам как мастеру в какие-то правила алхимии вставить отсылки на медицинские АК: "Если вы смешали ртуть с корнем мандрагоры, вы получили такое-то вещество, а еще отклейте у себя на медицинской АК полоску MER, поскольку вы отравились летучими парами ртути".
# Модель позволяет строить сколь угодно сложную систему взаимосвязей, ограниченную только способностью мастера держать в голове эту систему и способностью игрока держать в голове все, что ему говорят все действующие на данный момент у него АК. Можно смело уходить от олдскульной системы "2 нательных хита, любое оружие снимает один хит". Кстати, оффтопом: за несколько часов до меня Эдвин читал семинар о катках на больших полигонках, и Сега завел с ним интересную дискуссию, закончившуюся тем, что Эдвин заявил: "Вы нам только что создали модель медицины на Ведьмак". Так вот, медицина на "Ведьмаке" Эдвина, исходя из этой дискуссии, будет на аскольдокарточках :) <br>
UPD от 18.03.2014: если бы с нее все не ушли.
# Модель позволяет игроку не заниматься изучением сложных правил, а просто отыгрывать то, что написано на карточке. Зато изучать сложные правила придется игрокам, которые играют врачей. Что, в общем, тоже неплохо.
# Модель блокирует игроцкий произвол. Здесь отсылка к играм со сложной, но неконтролируемой системой медицины (тем же "Хогвартским Сезонам"), где игрок мог судить об успешности своего излечения только по словам врача. Что иногда (в совсем запущенных случаях) приводило к ситуациям, когда определенный игрок-врач считал своего персонажа способным лечить всех ото всего исключительно своей глубокой духовностью, полностью забивая на правила. Очевидно, что при наличии модели медицины на АК такой номер не пройдет - игрок просто заявит "Твоя духовность не подействовала, я продолжаю умирать".

И сразу после этого плюса переходим к минусам, поскольку этот плюс как раз имеет свою темную сторону.

# Детерминированность системы заодно означает ее полную закрытость. Т.е. если болезнь А в рамках модели лечится только заклинанием М или лекарством К, то для игрока не существует возможности изобрести на игре ритуал Т, который тоже будет лечить эту болезнь. А игроки, как известно, любят творить новое и выходить за границы старого. Если мастера планируют им это разрешить - им надо везти с собой на полигон принтер, ламинатор и пару лишних рабов для заклеивания карточек изолентой. Собственно, именно по этой причине многие игроки так не хотели введения АК на "Хогвартских Сезонах" - игре, на заре которой главмастером было постулировано "Все, что сделано красиво и волшебно - сработало, даже если это не по правилам".
# Сложность и время разработки. Для того, чтобы создать хорошую систему АК, нужно в соответствующую сторону заточенное мышление. Я знаю многих прекрасных мастеров, которые пишут прекрасные сюжеты и создают прекрасные модели правил, но если они попытаются создать модель-на-карточках - скорее всего, это будет ужасно.  Просто они мыслят другими категориями. В 90% случаев это выливается в "если нам нужна модель на аскольдокарточках, надо позвать Аскольда в мастера". Однако игр много, а Аскольдов мало. Да и в любом случае, даже если эту систему делает Аскольд - это довольно времязатратное занятие. <br />
Однако мало создать контент карточек - нужно еще их привести в пригодный для печати вид. Делается это либо долго и нудно руками (если у вас есть нужное количество маленьких рабов-верстальщиков), либо автоматизированно, в соответствующей программе. Однако пользоваться ей умеют хорошо если полдюжины человек. Вывод прежний - все идут к Аскольду. И опять же это времязатратно (хотя и не настолько, как ручная верстка и маленькие рабы). <br />
Впрочем, без маленьких рабов  все равно не обойтись - готовые карточки надо распечатать, заламинировать, заклеить изолентой, разрезать, и вот тут уже, будьте уверены, Аскольд этим заниматься не станет и правильно сделает.
# АХЧ-проблемы. АК - это не та вещь, которую можно доделывать в последний момент перед игрой, она требует внимания как задолго до игры (тесты, сыгровки), так и на игре. Например, если в какой-то точке полигона планируется активное взаимодействие с АК (например, в игровой больнице) - позаботьтесь, чтобы там на каждом углу стояла мусорка для использованных кусков изоленты, иначе они будут ровным слоем устилать пол и окрестности. Проверьте саму изоленту (некоторые сорта имеют обыкновение в теплом кармане отлипать от карточки и прилипать к соседям, а некоторые, наоборот, рвутся, но не отрываются).
# "Критические дни персонажа". Спрогнозируйте перед игрой ситуацию, в которой персонаж наберет себе максимально возможное для него количество карточек, дайте их неподготовленному человеку и посмотрите, насколько он с ними справится. Как правило, модели на АК строятся так, чтобы активных карточек было не очень много - но не всегда. Например, "Стоимость Жизни", больница. Пациент во время операции имел: 1-2 карточки активных болезней, 1 личную медкарту, 1 карту иммунодепрессанта, 1 карту кислородной подушки, 1 карту наркоза, 1 карту проводимой операции - итого 7 карточек, в которых таймеры были в среднем от 5 до 15 минут. В такой ситуации человеку приходилось играть не в ролевую игру, а в пасьянс с картами. Один игрок у нас по неопытности дважды за операцию умер, пока мы ему не показали, что вот та карта указывала ему открыть вот эту полоску, а вот эта полоска заставляла открыть вот эти две, а те две прекращали действие вот этой карточки, которая потом заставляла открыть вот то, из-за чего он умирал. Но не всем так повезло.

===Активные средства - музыкальный движок===
Музыкальный движок - относительно новая модель, примененная впервые на игре "Дом, в котором мир звучит" в 2013 году, мастера Надя Вечорек, Йолаф и Нэл. Работает он следующим образом: игрок до игры присылает мастерам набор музыки с отметками: такая-то композиция у меня ассоциируется со страхом, такая-то - с агрессией, такая-то вызывает романтичное настроение, а такая-то - желание бежать, действовать и спасать мир. На игре у каждого игрока есть плеер, в который мастерами заливается некоторый набор треков, состоящих из обработанной музыки игрока. Каждый трек имеет свое название на латинице. <br />
В игре существует такая игротехническая сущность, как Знаки. Это слово, записанное латиницей и заключенное в прямоугольную рамку. Как только игрок видит Знак (на стене, на предмете, на другом игроке), он должен найти в своем плеере трек с соответствующим именем и запустить его.

Пример: среди музыки, которую я посылал мастерам до игры, был "Танец рыцарей" Прокофьева, который, как я написал в сопроводительном письме, ассоциируется с неизбежно надвигающейся бедой, которая уже пришла, происходит, а дальше будет еще хуже. В какой-то момент на игре я пришел в лазарет, где лежала моя подруга, выбросившаяся из окна. На стене лазарета я увидел слово mrak, заключенное в рамку - это был Знак. Я открыл плеер и обнаружил в нем трек mrak.mp3, запустил - и это оказался тот самый "Танец рыцарей", который очень коррелировал у меня с печалью и жалостью по отношению к моей подруге.

Некоторые треки имели привязанные к ним триггеры. Означало это в рамках игры то, что определенная музыка действует на персонажа настолько сильно, что он не просто переживает эмоции внутри себя, но как-то проецирует на внешний мир. Например, триггер мог заставить персонажа, услышавшего определенную мелодию, бежать из помещения со всех ног. Или немедленно начать драку с наиболее несимпатичным для него человеком в комнате. Или поцеловать наиболее симпатичного.
К этой же модели была присоединена своеобразная Домовая "алхимия". Те, кто умел смешивать "вещества", знал специальные правила, по которым он формировал некий буквенный код, который и наносил на дно стаканчика с веществом. Человек выпивал то, что было намешано, видел код (что-то типа fabrwg), отыскивал нужный трек у себя в плеере и слушал, как его торкнуло от того, что он выпил. Или не торкнуло - если соответствующего трека не было.

Специально к игре "Атлантис" ТГ Остранна эту модель решила перенести на браслет игрока. Музыка играет через наушники непосредственно с браслета, а вместо Знаков стоят радиоизлучатели, передающие сигнал вида "запусти музыку с таким-то названием", позволяющие всем в кабаке слышать какой-нибудь веселый go-go, а в прериях и пустыне - медленный блюз. 

Главный плюс такой модели - это невероятная мощность воздействия на игрока. Одно дело - отклеить полосу на аскольдокарточке и прочитать "у тебя боевое настроение, ты готов драться", а другое - слышать у себя в ушах музыку, которая действительно вызывает у тебя боевое настроение и желание драться. Музыка - вообще хороший инструмент воздействия на эмоции, отсылаю всех интересующихся этой темой к соответствующему семинару Шагги.

Еще один существенный плюс - плеер достаточно небольшой по размерам, свободно влезает в карман, наушник можно замаскировать волосами, а провод - спрятать под одежду или заклеить пластырем телесного цвета, и человек с плеером никого не будет выбивать из игры, будь то историчка, фэнтези или киберпанк.

Кроме того, система игрокоориентированна. Ничего не мешает на один и тот же Знак для разных игроков повесить разные по смыслу мелодии. Например, в месте большого скопления народу повесить Знак, который вызывает у персонажа-экстраверта живость и веселье, а у социофоба - желание куда-нибудь уйти, желательно побыстрее и подальше.

Что касается недостатков движка - в первую очередь хочется отметить, опять же, времязатратность работы с ним, плюс более высокий входной порог. Любой человек может отредактировать текст в текстовом редакторе, но для редактирования музыкального файла надо иметь, во-первых, соответствующую программу на компьютере, во-вторых, навыки работы с ней. Там, в принципе, нет ничего сложного, и эти навыки можно получить за полчаса, но нужен человек, который покажет, как это делается. Ну, и просто музыку редактировать сложнее и дольше, чем текст. И всегда надо заранее озаботиться тем, чтобы на полигоне на всех ноутах стояла программа для редактирования музыки, и все мастера были с ней знакомы.

Из этого вытекает следующий вывод: музыку игроки должны присылать сильно заранее. Минимум за месяц до игры. Иначе мастера могут просто не учесть всех тонкостей. Опять же, пример из печального личного опыта: у меня Знак smejus начинал звучание композиции Contradanza Ванессы Мэй, а на эту композицию мастера мне дали триггер - сначала я смеюсь, как ненормальный, потом так же беспричинно рыдаю. Однако оказалось, что Знак smejus есть в спальне, где я жил, в двух главных коридорах, в столовой и в Кофейнике - т.е. в местах, где я проводил 80% игры. После третьей подряд истерики, когда меня доставили в лазарет с явным подозрением на психоз, мне пришлось идти к мастерам и разруливать эту проблему.

===Активные средства - флешбеки===
Довольно простой механизм, который использовался, например, на игре "Зомби: АмнеZия". Игроку выдается несколько закрытых пронумерованных конвертов, а в аусвайсе пишется памятка вида:
* если ты впервые за игру увидел зомби - открой флешбек №2
* если ты впервые подчинился чьему-либо приказу - открой флешбек №7
* если ты выпил Кока-Колы - открой флешбек №9, при условии, что у тебя есть уже минимум два открытых флешбека
* если ты принял участие в драке - открой флешбек №4 или №5 на свой выбор, после следующей драки открой второй из них

И т.д. Метод прост и очевиден. Плюс - передавая, в общем-то, малый объем информации (номер флешбека, который надо открыть), мы даем игроку большой объем игровых знаний (некоторые флешбеки могли занимать несколько листов А4). Минус - мастеру надо четко спланировать, не только "какую именно информацию передать игроку", но и "в какой ситуации". Ну и, само собой, редко применимо на играх, где персонажи не страдают амнезией.

==Интерактивные средства - общий обзор==
Интерактивные средства, как уже было сказано, подразумевают, что у игрока имеется некоторый предмет с электронной начинкой, позволяющей не только отдавать игроку заранее заложенную в них информацию, но и получать некоторые сигналы извне - как от самого игрока (ввод команд, данных), так и от встроенных в них средств ввода (камер, акселерометров, радиоприемников, GPS или ГЛОНАСС-модулей, датчиков освещения и т.д.). На основе имеющейся и полученной информации такие средства способны порождать новую информацию и делиться ей с игроком.

Интерактивные средства делятся на две основные категории - широкофункциональные и узкофункциональные. Под узкофункциональными я здесь понимаю изобретения техномагов нашего времени - ТГ "Остранна" (светящиеся при приближении орков кинжалы, говорящие портреты, электронные замки с кристаллами, ведьмачьи перчатки и т.д.), Ксотара и Максая (инфракрасные пушки, радиолюстры и т.д.), Ранмы (ремонтные коробочки) и других. Эти вещи отличает то, что они имеют совсем немного функций, зато делают их точно и надежно. И если вы хотите использовать у себя в игре такую вещь, которая уже была разработана, то это достаточно просто - приходите к нужному человеку (Крейлу, Йолафу, Ксотару, Максаю и т.д.) и говорите: мне нужна такая-то ваша разработка в таком-то количестве. Вам говорят, сколько это займет времени и сколько будет стоить. Дальше - вопрос договоренностей.
Если же вы хотите "такого же, но с перламутровыми пуговицами", что может потребовать перенастройки девайса, перепрошивки или чего-то подобного - то порядок действий тот же, но приходить надо значительно раньше. Желательно - минимум за полгода, а лучше - в тот самый момент, когда у вас появилась идея использовать такие вещи на своей игре. Откладывать все на последнюю неделю - очень неудачная затея, потому что, даже если вы хотите что-то уже существующее и давно отлаженное, кто поручится, что как раз в это время эти вещи не отдали другим мастерам, которые просто раньше подсуетились?

Дальнейшая часть доклада будет значительно сложнее для неподготовленного читателя, поэтому, если чувствуете, что чего-то не понимаете - обращайтесь напрямую ко мне. Я постараюсь говорить простым языком, но это в любом случае не легкое развлекательное чтение перед сном.

===Интерактивные многофункциональные средства - с чего начать?===
Вторую широкую группу интерактивных средств, а именно многофункциональные, я в дальнейшем буду называть КПК (карманный переносной компьютер). Они характеризуются наличием в них памяти, в которую можно загрузить внешнюю программу, процессора, который может эту программу исполнять, и средств ввода-вывода для получения новой информации и сигналов и отображения сгенерированных данных для игрока. В качестве КПК может выступать, например, браслет игрока, мобильный телефон, смартфон, планшет, ноутбук, даже электронная книга, если она позволяет загружать программы извне.

Первый вопрос, на который вы должны дать себе ответ - какие именно технологические возможности КПК нужны будут вам для вашей игры. Например, нужно ли вам геопозиционирование (отслеживать, куда игроки перемещаются в течение игры), акселерометр (фиксировать какие-то жесты руки, к примеру), датчик движения, датчик освещенности, температуры, мало ли чего еще. От этого напрямую зависит, какой именно КПК вам подойдет. Например, если вы планируете использовать на своей игре ксотаропушки, лучшим выбором будет браслет игрока, поскольку только он имеет возможность взаимодействовать с ними напрямую, в нем уже реализован готовый интерфейс. А если вам потребуется, например, GPS-позиционирование, тут подойдет планшет или телефон с GPS. Впрочем, по факту у вас не так много различных возможных платформ, на которых будет крутиться ваш программный комплекс. Это:
* веб-приложение. Может запуститься на любом планшете или ноутбуке. Дешево и сердито - веб-программиста сейчас найти довольно несложно. Но при этом, если вы используете планшет, вы сильно ограничены в использовании встроенных средств. Если данные от GPS-датчиков вы еще сможете получить в веб-приложение, то, например, акселерометр или камеру к нему прикрутить, скорее всего, не получится.
* приложение под родную операционную систему планшета. Вариант на случай, если вам нужен, например, акселерометр и другие встроенные датчики. Сможете в полной мере использовать на планшете с такой операционной системой (например, Android, iOS, Windows Mobile), ограниченно - на ноутбуке с эмулятором (запустить-то вы запустите, но акселерометра в ноутбуке просто физически нет), и вообще не запустится на планшетах/телефонах с другой операционной системы. Да, приложения под iPad/iPhone не запустятся под Андроидом, а андроидские - под Windows Mobile, и наоборот. Программисты, пишущие программы под эти платформы, распространены примерно поровну. В принципе, можно написать три варианта программы под три разные операционные системы, но это будет долго, хотя и вполне реально. Даже более реально, чем, например, обеспечить всех игроков айпадами.
* приложение под браслет игрока. Единственный возможный язык программирования - С++, программисты на нем - звери редкие. Теоретически такое приложение может запуститься и на ноутбуке, но смысла в этом будет чуть больше, чем нисколько, потому что ноутбук не обладает большей частью тех возможностей, которые есть в браслете (и наоборот).

Выбирая платформу и тип приложения, на самом деле, стоит в первую очередь ориентироваться на того, какого программиста вы можете привлечь к своему проекту. Даже если у вас просто неимоверные планы на браслет игрока, но в ближайшей эпсилон-окрестности у вас нет ни одного человека, слышавшего о С++ - вам придется либо искать программиста по найму, либо отказываться от этой своей идеи вообще.

Кстати, еще один маленький хинт для мастеров, которые не уверены, что их игра способна захватить внимание игроков на все 100%: игрок с браслетом игрока (в отличие от игрока с планшетом или мобильником) никогда, заскучав, не сядет в углу играть в Angry Birds :)

===Интерактивные средства - связь===
Второй вопрос, который вы должны для себя решить - будет ли ваш КПК иметь возможность связываться с мастерским сервером. Вообще - это дело исключительно приятное, например, на какой-нибудь игре по Манчкину устроить "божественное вмешательство" и одновременно повысить всех клириков на 1 уровень. Но сразу же нужно решить - какие именно методы связи для вас подходят. Универсального решения тут нет, все зависит от полигона.

====Мобильная связь====
Использование мобильной связи на игре может быть надежным только в том случае, если вы уверены, что мобильная сеть выдержит ваши объемы передачи информации (читай, трафика мало, или игра идет в городе). Например, Хогвартские Сезоны, там было несколько человек (до 10) - членов Ордена Феникса, которые могли посылать говорящего Патронуса (отыгрывается смской), причем делается это не регулярно, а 5-6 раз за день. Конечно, такую нагрузку мобильная сеть даже не заметит. Но, может быть, ваша система подразумевает, что у вас 300 игроков на игре, и каждому из них рассылается по смске раз в минуту, а ваш полигон находится где-то in the middle of nowhere в глубоких лесах в пяти километрах от ближайшей деревни с одной мачтой мобильной связи, рассчитанной на 100 человек (при том, что 80 уже есть в деревне). В этом случае будьте уверены, что через пять минут после начала игры мобильная связь бодро издохнет и у игроков, и у вас, и у деревенских. Даже если перед игрой вы тестировали связь, например, впятером с разных концов полигона. Лишних 5 человек местная мобильная сеть даже не заметит, а от лишних трехсот - умрет смертью храбрых. Кроме того, даже если у вас нет таких умопомрачительных объемов - все равно, на некоторых полигонах мобильная связь работает тупо плохо. Известен случай, когда смска шла с одного конца полигона на другой 40 минут. Еще раз: 40 минут.

====Мобильный интернет====
К нему можно отнести ровно те же слова, что уже были сказаны о мобильной связи. Кроме того, не забывайте - мобильный интернет и в пределах крупных городов может не отличаться приличной скоростью, а уж в лесах - тем более.

====Локальная сеть====
Раскинуть по полигону локальную сеть обычно возможно в условиях базы или одного здания, но, как показал опыт "Стоимости Жизни", локалку можно раскинуть и посреди леса, если у вас есть достаточно оборудования и рукастых людей. Довольно неплохо об этом писал админ "Цены Чести" Дима (http://submaster.livejournal.com/75128.html), в своем посте он дает изрядно полезных советов по обходу подводных камней. В любом случае, вам придется найти администратора локальной сети, который не будет на игре заниматься больше вообще ничем. Не играть, не мастерить - только следить за сетью. Совмещать - реально плохая идея, как известно, "если вы одной рукой ведете машину, а другой обнимаете девушку - вы и то, и другое делаете плохо".

Есть, правда, одна небольшая проблема - даже если локалка у вас на полигоне работает совершенно безукоризненно, ни в один КПК (ну, кроме ноутбука) вы при всем желании не воткнете сетевой кабель. А если и воткнете - игрок, без сомнения, его вытащит, если ему захочется пойти посекретничать в другую комнату. Поэтому такой вариант применим только для статичных точек доступа, где планируется большой обмен трафиком с мастерским сервером (например, в игровой больнице или научном центре).

====WiFi====
Довольно логичное продолжение прошлого пункта - на каждый конец сетевого кабеля поставить по wifi-роутеру и раздавать беспроводную сеть вокруг себя. Хороший вариант, если у вас хватает оборудования и питания для всего этого зоопарка устройств. Основных проблем две: пропускная способность точки и экранирование. Пропускная способность одной wifi-точки довольно невелика, и если в одной комнате, например, 20-30 человек одновременно начнут пользоваться связью - с вероятностью они намертво забьют канал и все будут страдать от низкой скорости. Что до экранирования - существует такая беда, что wifi распространяются через радиоволны 2.4 ГГц, а они замечательно экранируются буквально чем угодно - начиная от человеческого тела, кончая мокрой листвой, что мы опять же наблюдали на "Стоимости Жизни", где дождь намертво обрушивал сеть во всем Нью-Венисе - не потому что промокало оборудование, а потому что промокал лес.

====Радиоканал====
Радиоканал - на самом деле, неправильное название, поскольку никакого "канала" не существует, радиосвязь подразумевает передачу во все ближайшие окрестности - кто услышит, тот услышит. Соответственно, нет гарантии, что вас услышал именно тот, кто вам нужен, и нет гарантии, что не услышал тот, кому это не нужно. Можно, конечно, пытаться организовывать протокол с подтверждением получения, но дело это нелегкое, и если вы способны такое делать - то эта часть доклада для вас явно неинтересна. Говорят, что в эту сторону что-то уже придумали "Белые Орлы" - кому интересно, переадресую к ним. В целом, радиосвязь успешно используется в тех случаях, где контроль получения не очень важен. Например, у Остранны в кинжалах, которые светятся при приближении орков, есть приемник, а у орков есть передатчик, который передает сигналы, допустим, раз в секунду. Ну не получит кинжал сигнал в эту секунду, получит в следующую. Не получил в следующую, получит через одну. В принципе, эльфу не так уж и важно, учует кинжал орков за 150 шагов или за 145. Применимо ли это в вашем случае - думайте сами.

====Оптический сигнал====
Тут одно слово - ксотаропушки. Инфракрасный луч позволяет передавать информацию с приличной скоростью и на значительное расстояние, другое дело, что чем больше расстояние, тем больше шансов, что на пути сигнала что-то появится (помните классический мем с башорга "На пути нашего сигнала ВНЕЗАПНО построили дом" - слово ВНЕЗАПНО, вообще-то, оттуда). Это не обязательно что-то большое и непрозрачное - пыль, дым, водяная пыль тоже могут значительно исказить траекторию луча. Плюс необходимость держать приемник и передатчик в абсолютной неподвижности. Все-таки стрельба из ксотаропушек - более удачное применение такой связи, чем передача важной информации, которая должна дойти без искажений.

====Bluetooth====
Этот способ связи позволяет передавать информацию на совершенно смешную дистанцию - около десятка метров. Наладить взаимосвязь между двумя КПК двух игроков это позволяет, а вот достучаться до мастерского сервера - почти никогда, если нет никаких средств ретрансляции, построенных на других методах связи. Поэтому, например, для игры на большом полигоне это тоже не идеал

===Интерактивные средства - толстый и тонкий клиент===
Следующий вопрос, который вы должны для себя решить, если уж решились использовать КПК со связью - какой у вас будет клиент, толстый или тонкий. Если связи нет, единственный вариант для вас - толстый клиент. В чем их разница?
На первой схеме изображен толстый клиент. Синей рамкой обозначены компоненты, входящие в состав одного КПК. В каждом КПК есть локальное хранилище, в котором размещаются данные, нужные для работы приложения - например, текущий уровень силы персонажа, количество его здоровья, возможно - количество денег, возможно - текущие болезни. Словом, все, что только обрабатывает приложение. Там же, в КПК, находится и само приложение, которое обрабатывает эти данные. Это приложение знает бизнес-логику (т.е. что как работает согласно правилам). Например, "если у персонажа меньше максимального запаса хитов, он теряет по одному хиту раз в полчаса" - это элемент бизнес-логики).
Наконец, на КПК есть еще и интерфейс - т.е. средства, благодаря которым в него вводится новая информация (датчики, GPS-модуль, кнопки, сенсорный экран), а также средства, благодаря которым игрок может получать информацию от КПК (экран, динамик, светодиоды, вибропривод и т.д.)      

ТОЛСТЫЙ КЛИЕНТ

ТОНКИЙ КЛИЕНТ

Тонкий клиент, в отличие от толстого, подразумевает, что все данные обо всех персонажах хранятся на мастерском сервере. И программа, которая их обрабатывает, тоже находится на сервере. Функции КПК в этом случае - запрашивать необходимые ему данные ("А сколько сейчас хитов у Леголаса?"), получать ответ от сервера и отображать результат в понятном для игрока виде (например, картинкой/текстом на экране).

Тонкий клиент позволяет мастерам в любой момент, во-первых, знать состояние любого персонажа, во-вторых, свободно его менять. Расплата за эту гибкость - опасность того, что если все (или даже некоторые) КПК потеряют связь с мастерским сервером, они останутся без информации вообще. Если же клиент толстый, то при обрыве связи уже запущенные в нем процессы будут спокойно продолжаться и без какого-либо вмешательства мастерского сервера. Хиты раненого будут продолжать уменьшаться, мана мага - восстанавливаться, и т.д. Учитывая, что при нынешнем технологическом уровне полную гарантию работоспособности любой сети вам не может дать даже страховой полис, толстый клиент почти всегда - более удобное решение в условиях безынтернетья. Тонкий хорош, например, при городской игре, особенно если доступ идет по надежным линиям связи.

==КПК - схема разработки программного продукта==
Разработка ПО для ролевой игры по составу участников напоминает карту Таро "Тройка Жезлов", одна из трактовок которой гласит, что для строительства храма нужны три человека: священник, который знает догматы веры и определяет, как должно выглядеть получившееся, архитектор, который умеет проектировать и создавать здание так, чтобы оно не развалилось, и шут - чтобы эти двое не перессорились между собой. В рамках нашей модели мастер - это священник, программист - архитектор, а для связи с ними нужен отдельный человек, называемый менеджером проекта (Project Manager, PM).

Можно ли обойтись без РМ? Практически нет, если только мастер или разработчик сами не возьмут на себя эту обязанность. Но в первом случае это означает, что мастер должен быть хоть как-то знакомым с процессом разработки программ, а во втором - что разработчик досконально знает мир игры и модель правил. Иногда, что приятно, какое-то из этих требований выполняется. Но вполне возможен вариант, что мастер будет делать круглые глаза от вопроса типа "Можно ли наследовать солдата и мирного персонажа от одного базового класса, или у них мало пересекающийся функционал?", а программист может быть приглашенным со стороны, не ролевиком, не знать разницу между кулуаркой-действием и кулуаркой-предметом, а под словом "чип" вообще подразумевать электронный элемент на печатной плате. В этом случае вам точно потребуется РМ.

Разработка программного продукта состоит из следующих этапов.

* Мастер создает модель мира

Модель мира в голове мастера практически всегда представляет собой модель нашего реального мира, которая есть у мастера в голове изначально в силу того, что мастер живет в этом мире всю свою жизнь и обладает некоторым багажом знаний о нем. На модель  нашего мира накладывается какая-то дельта, совокупность изменений, отличающий мир игры от нашего. Взять наш мир, отмотать несколько веков назад, перенести действие во Францию - получим "Три мушкетера", оставим наше время, но перенесемся в Британию и добавим волшебные палочки - будет "Гарри Поттер". Останемся в России, добавим оборотней, вампиров и Сумрак - получим "Дозоры", заменим Сумрак на Институт Прикладной Экзофизики - будет нам "Эра Водолея", а если на набор древних рас - "Тайный город". Все, что не входит в дельту, остается таким же, что и в нашем мире. Например, если в первоисточнике не сказано иного - в мире есть мужчины и женщины, они рождаются, растут, производят потомство, старятся и умирают.

* Мастер создает концепт

Концепт - это теория всего, описывающая ту область игровой реальности, которая впоследствии будет моделироваться программой на КПК. Для каждого блока правил - свой концепт, и эти концепты в идеале должны быть связаны и непротиворечивы. Концептуальная теория должна быть способна отвечать на каверзные вопросы по этому аспекту мира, причем не только "Так или не так?", но и "а почему так?". Именно в концепте должны быть заложены факты, позволяющие мастерам решать все спорные случаи и вопросы до и в процессе игры. Могут ли друиды научиться заклинанию "огненный шар"? Может ли в мире Лукьяненко вампир быть светлым? Можно ли лечить некроманта святой магией? Может ли кендер стать паладином?

* Мастер пишет правила
Тут уже все понятно - это те правила, что выкладываются в мастерском сообществе, рассылаются игрокам, бывают открытые, закрытые и т.д. Собственно, на этом мастер считает свою работу законченной. И, если бы не необходимость разработки программы, он бы был прав в этом решении. Но просто выдать программисту правила в надежде, что дальше он сделает все круто - это верный способ провалить проект. Поэтому дальше в дело вступает наш "шут" - менеджер проекта.

* РМ разрабатывает бизнес-логику.
Бизнес-логика разрабатывается на основе того, что сделано мастером в пп. 2 и 3, т.е. концепт и правила. Бизнес-логика - это та же модель мира, только максимально облегченная, из нее выброшено решительно все, что не имеет своего отражения в той модели, которую будет реализовать программист. Потому что для описания какой-то сущности человеческим языком может хватить двух-трех фраз, а для того, чтобы создать ее математическое воплощение в программе, может уйти два-три дня. Отсюда, задача РМ - сделать бизнес-логику максимально простой, лаконичной и непротиворечивой. Ключевое слово - все-таки "лаконичной", например, если в модели медицины, которую вы реализуете в виде программы для КПК, нет никакой разницы с медицинской точки зрения между мужчиной и женщиной, то в рамках бизнес-логики не существует мужчин и женщин, есть "абстрактные люди".

* РМ разрабатывает техзадание
Далее на основе бизнес-логики и правил игры РМ разрабатывает техзадание. Техзадание (ТЗ) - это священная корова программиста, в нем должно быть с начала до конца описано все поведение программы, что как считать, какая форма по какой кнопке вызывается, и т.д. В ТЗ не должно быть никаких недосказанностей, умолчаний и обобщений, потому что программирование - самая благодатная почва для исполнения законов Мерфи, один из которых, в частности, гласит "Все, что может быть понято неправильно - будет понято неправильно". Кроме того, любая короткая фраза в правилах, с точки зрения мастера, предельно понятная, может усложнять бизнес-логику (а следовательно, и ТЗ) в разы. 

Например, мастер написал в правилах что-то вроде: "Для тех, на ком лежит благословение Элуны, это заклинание действует сильнее". Одна простая короткая фраза. Для РМа она сразу порождает море вопросов. Как именно сильнее? Насколько сильнее в абсолютных цифрах (в процентах, в длительности)? Что такое благословение Элуны, кто может его получить, каков механизм этого? Можно ли его потерять? Оно существует в формате "или есть, или нет", или бывает сильнее/слабее? Влияет ли оно на восприимчивость к другим заклинаниям? Есть ли благословения других богов, которые тоже влияют на эффекты заклинаний? Если да, как они сочетаются между собой? И т.д.
Формировать ТЗ желательно совместно с мастером (а еще лучше - и с программистом). Потому что грамотный РМ всегда может убедить, что вот такая вот фишка, давая микроскопические преимущества, усложняет разработку значительно, а потому не отказаться ли от нее в пользу чего-нибудь другого, еще более интересного?

* Программист создает объектную модель

Делает он это на основе бизнес-логики и техзадания. Здесь уже бизнес-логика, которую РМ представил в виде словесных описаний, схем и графиков, переходит в компьютерное представление. Информация вида "У любого персонажа есть имя, возраст и раса (человек, эльф, гном, орк), от которых зависят его магические способности" преобразуется в вид "Любой объект типа Персонаж имеет свойство "имя" - строка символов, свойство "возраст" - число, и свойство "раса" - выбор из 4 вариантов" и записывается на понятном компьютеру языке.

* Программист имплементирует бизнес-логику

На этой стадии все сущности, описанные РМ в бизнес-логике (персонажи, заклинания, болезни, монстры - что угодно, в зависимости от программируемой модели), уже имеют своих цифровых "двойников" внутри программы. Дальше программист на основе ТЗ делает имплементацию. Т.е. непосредственно описывает взаимодействие этих сущностей друг с другом с программной и математической точки зрения: "Если объект Х применяет на объект Y заклинание лечения, то: 1) у объекта Х свойство "количество маны" уменьшить на 20, 2) у объекта Y свойство "здоровье" увеличить на 50"

* Программист создает интерфейс

Далее программист (опять же, на основе ТЗ) делает так, чтобы программа могла получать данные от пользователя и возвращать ему интересующую его информацию. В какое меню лезть, чтобы применить заклинание? На какую кнопку жать, чтобы дать команду "В меня попала стрела, обработай!"? Как разнести информацию о персонаже (здоровье, мана) и информацию о самом КПК (уровень сигнала, заряд батареи)?

* Тестирование

Тестировать должен РМ, а не программист. Это не обсуждается. У программиста за время разработки от постоянного взаимодействия с программой глаз замыливается начисто, и некоторые не совсем очевидные вещи он, скорее всего, пропустит. Т.е. если персонаж применяет заклинание Лечения, а оно не работает - это, скорее всего, программист заметит сам. А вот то, что этим заклинанием персонаж может лечить стены и камни - скорее всего, не заметит. Или что заклинание действует на уже умерших персонажей с отрицательным количеством хитов. Такие вещи должен находить и отсекать РМ (возможно, с помощью других тестировщиков, например, мастера). Программисту-то что, он может вообще не знать, что такое "хит", и не соотносить его с мерой живучести персонажа. Для мастера, у которого в голове есть картина мира, концепт и правила, факт, что количество хитов персонажа всегда неотрицательно - абсолютно самоочевиден, и никакого дополнительного обоснования не требует. А программисту-то что, ему сказали "хиты - это число", и ему все равно, каким это число будет - хоть отрицательным, хоть дробным, хоть комплексным. Этот момент и должен отсекать тестировщик (хоть РМ, хоть кто еще) и сообщать программисту: слушай, количество хитов всегда должно быть неотрицательным, как упало меньше нуля - персонаж мертв, лечить его нельзя.

Немного иллюстраций из практики. Когда я писал медицинское приложение (автодок) к игре "Открытый Космос", я не раз сталкивался с тем, что данные пациента математически изменяются по тем формулам, которые я вложил в программу, но нисколько не стыкуются с реальными медицинскими знаниями. Т.е., например, дав пациенту слишком много жаропонижающего, можно было понизить температуру его тела ниже нуля. Впрочем, пациент с отрицательной температурой тела - это удивительно, но хотя бы физически возможно, а вот с отрицательным давлением и пульсом...

Впрочем, эту ошибку я исправил довольно быстро (в этом сильно помогало то, что я там был и программистом, и РМ, а впоследствии стал и мастером). Дальше получился фокус с формулой, которая определяла скорость кровопотерь в зависимости от количества крови в организме (понятно, что чем меньше крови в теле, тем медленнее она вытекает). Однажды, дав пациенту слишком много кроветворного, я добился того, что в пациенте оказалось больше 6 литров, и неудачно составленная формула дала отрицательную скорость кровопотери. И пациент начал всасывать кровь из ниоткуда, ее становилось все больше, и чем сильнее я кромсал его скальпелем, тем быстрее бездушная формула напитывала его новой кровью, которой неоткуда было взяться физически, но с математической точки зрения все происходило согласно заданным правилам. Излишне и говорить, что после этого формула была изменена (еще и потому, что если в пациенте оказывалось ровно 6 литров крови, не больше, не меньше, пациент немедленно погибал от деления на ноль).

А вот еще одна ошибка дошла до самой игры и так и осталась. Когда я проанализировал последовательность действий при операции, выяснилось, что для операции на мозге нужно делать те же действия, что и для операции, скажем, на почках. Т.е. с точки зрения системы мозг человека находился у него в животе. Вряд ли это на игре кто-то заметил, но меня на тот момент это изрядно посмешило.
 
Собственно, на этом модель разработки зацикливается, повторяются пункты 7-8-9 (иногда заскакивая и на 6), пока не будут реализованы все пришедшие мастеру в голову фишки и не исправлены все найденные баги. Или не будет горестного крика "Аааа, завтра игра, ладно, заливайте как есть!"

===Взаимодействие с программистом - "индус"===
Программисты бывают разные. И подходы к разработке программных продуктов у них тоже разные. Это обязан знать РМ (чтобы знать, когда пинать, а когда отойти и не мешать), и неплохо бы знать мастеру. Здесь я рассмотрю три характерных архетипа программиста - просто чтобы вы знали, с кем (и с чем) вам, возможно, придется столкнуться.

Итак, первая разновидность программиста - это "индус", сторонник парадигмы программирования, которую другие разработчики презрительно называют "индусским программированием", а также "быдлокодингом" и "говнокодингом". Рассмотрим этих граждан поближе.
Индус - это чаще всего низкоквалифицированный программист. Возможно, школьник, возможно, студент, не особо интересующийся программированием, иногда даже выпускник формата "права купил, а ездить не купил". При этом он может быть даже умным и смышленым программистом (хотя это редкость) - т.е., в терминах DnD, у него высокий Интеллект, но низкая Мудрость.
Низкая квалификация влечет за собой то, что он плохо знает среду программирования. Поэтому даже простые задачи он иногда решает путем создания изрядного количества "костылей" и "велосипедов". Это может круто работать, а может и не работать. Программа индуса на взгляд профессионала напоминает картину - в лучшем случае сюрреалистическую, в худшем примитивистическую.
Зависимость времени, которое индусу нужно на разработку программы, от сложности программы, выглядит так:
С этим парнем мало кто сравнится в скорости, если программа реально проста (для его уровня) - он всегда старается делать все настолько просто, насколько возможно. Но при усложнении программы требуемое ему время растет экспоненциально, а программа начинает напоминать "Нору" семейства Уизли - тут два этажа, тут три, здесь какой-то флигель на каких-то костылях стоит, там водосточная труба скотчем примотана, чтобы не отвалилась, там остатки какого-то сарая, который никем не используется, но если его снести, то с северной стороны дома крыша проваливается. В программе индуса при ее усложнении появляется дикое количество неочевидных связей и зависимостей, поэтому с какого-то момента сложность программы доходит до экстремума, и уже сам индус не в силах внести даже простые поправки, потому что это влечет за собой лавину изменений в самых странных местах, и эта лавина погребает его в процессе бесконечной ловли багов. Единственное средство против этого - сразу дать ему абсолютно полное и точное ТЗ и не менять его в процессе разработки. Впрочем, боюсь, не родился еще тот заказчик, у которого ТЗ никогда не меняется. Это относится не только к программному обеспечению для ролевых игр, но и к коммерческому.

Нужно сразу сказать: если вдруг вы со своим индусом рассорились и позвали другого программиста дописать его слегка незаконченную программу - 99%, что другой программист ужаснется и скажет: "Тут проще все заново переделать, чем в этом <экспрессивное определение>  разбираться". В общем-то, это правда - практически всегда, практически для любого программиста и практически для любого проекта. Остановить программиста от такого шага может только то, что сделано уже много, осталось уже мало, да и время поджимает. Но если времени еще достаточно - подумайте, может, действительно, пусть новый программист перепишет все заново? В противном случае вы получите ОЧЕНЬ медленно работающего разработчика с ОЧЕНЬ плохим настроением. Вообще все программисты не любят дописывать чужой код, а уж индусский - в квадрате не любят.

===Взаимодействие с программистом - архитектор системы===
Это полная противоположность индуса. Это, как правило, старшие разработчики и тимлиды в компаниях, которые занимаются именно что программированием (а не цветочный магазин с IT-отделом из двух человек, поддерживающих сайт-визитку). Если вы решили привлечь к своей разработке такого человека, перед вами стоит две задачи. Первая - это сразу составить толковое и по возможности полное ТЗ. Без ТЗ архитектор палец о палец не ударит, хотя при хорошем отношении к вам может помочь вам его составить (у него этих ТЗ за плечами - не один десяток, думается). Второе - вам надо заинтересовать его своим проектом. Потому что, принимая во внимание зарплаты таких граждан (иногда шестизначные или около того), заинтересовать их деньгами будет сложно. Точнее, не сложно, но явно чересчур затратно для бюджета вашей игры. Впрочем, не надо думать, что это невозможно. На том же "Открытом Космосе", насколько я помню, весь софт писался бесплатно, за идею, хотя если перемножить количество человеко-часов на среднюю зарплату тех, кто этим занимался, я бы оценил софт ОК где-то в районе 0.5 - 0.7 миллиона рублей.  

Однако вернемся к нашему архитектору. Это опытный человек, он знает, что заказчик при всех советах с его стороны никогда с первого раза не напишет полного ТЗ, обязательно что-то забудет. Поэтому в объектную модель он заранее закладывает здоровенную кучу возможностей на случай "а вдруг пригодится". Напомню вам старый анекдот:

Приходит студент-программист к своему научному руководителю: <br />
- Профессор, я никак не могу придумать тему для своего диплома.<br />
- Ну, создайте программную модель скачек на ипподроме.<br />
На защите диплома:<br />
- Ну, мой дипломант не до конца выполнил задание, но, насколько я понял, достиг определенных успехов?<br />
- Да, профессор, я создал модель скачек для сферического коня в вакууме.<br />

Можете быть уверены, герой этого анекдота - будущий системный архитектор, предвосхищающий то, что кому-то из приемной комиссии захочется, чтобы на программном ипподроме бегали не только кони, но и, скажем, ослы и ламы, другому - установить там марсианскую гравитацию, а третьему - убрать атмосферу. Поэтому он закладывает в модель все сразу. Закономерно не успевает до конца, но если дать ему еще пять лет времени, 10000$ и штат помощников (как это постулируется в другом варианте анекдота), то он создаст шедевр. Вот его график работы:

Фигурально выражаясь, даже для маленького сарая этот программист закладывает фундамент примерно с гипермаркет размером. Ну а чего мелочиться, все равно заказчик захочет расширить возможности программы. А не захочет - сам расширю, что я - ребенок, что ли, одним сараем ограничиваться? Проблема для вас как для мастера не в том, построит ли он этот гипермаркет или нет (можете не сомневаться, построит, если не заленится), а в том, когда это будет. Может статься, что одно только строительство фундамента займет все оставшееся до игры время. 

Но зато если у вас времени до игры много (особенно если игра - сезонная), а система реально большая и сложная - этот парень находка для вас! Ему хватит компетентности, чтобы оценить сложность всей системы и заложить под нее подходящих размеров базу. Впрочем - упаси вас Бог попросить сделать что-либо, не вписывающееся в его платформу. Скорее всего, он скажет "это невозможно". Понимать эту фразу следует так: "Раз уж ты не сказал о том, что такая возможность вообще существует в этом мире, мне придется уже имеющуюся платформу ставить на еще более широкую и толстую. Я это сделаю, но к тому времени твоя игра уже три раза пройдет". В общем, можете не обижаться, а просто принять на веру, что это в принципе возможно теоретически, но вашу игру эта теория никак не спасет. Просто откажитесь от задуманной фишки.

Если же вдруг вы рассорились с таким человеком и просите его код дописать кого-то другого, будьте готовы к тому, что работа будет проходить по принципу "Удар молотком - 3 рубля, поиск правильного места для удара молотком - 5000 рублей". Ну, или надейтесь, что он писал код с комментариями и документацией.

===Взаимодействие с программистом - экстремал===

Экстремальное программирование - это не мой неологизм, это вполне официальный термин. Эта методология представляет собой более-менее сбалансированную середину между двумя предыдущими вариантами. Программист-экстремал никогда не пытается выбить из заказчика все ТЗ целиком - он знает, что заказчик на это не способен. А в процессе изменения ТЗ вы будете от него слышать фразы примерно в такой последовательности:

- Погоди, сейчас мне надо создать подходящую объектную модель.<br />
- А теперь я уже могу реализовать все то, что ты хочешь.<br />
- Хочешь такую фишку? Без проблем!<br />
- И такую? Сейчас, минутку... готово!<br />
- Слушай, а здесь у тебя как должно работать?<br />
- Так??? Что ж ты сразу не сказал?! Аааааа!!! Придется все целиком переделывать.<br />

Вы пьете валокордин и только готовитесь уйти с горя в запой, как он сообщает, что это "все" будет готово завтра. Максимум - послезавтра. Через два дня приходит к вам радостный:<br />

- Ну вот, теперь модель может все! И то, что ты просил, тоже!<br />
- А еще знаешь, что тут можно сделать? Вот такую фишку вставить! И очень просто! Я такую возможность заложил!<br />
- Такую? Ну ладно, я на это не рассчитывал, но ничего, сделаю.<br />
- А вот об этом вообще надо было с самого первого дня предупреждать! Теперь опять придется все переделывать с самого начала!<br />

И так проходит несколько циклов - "можно все", "можно все, кроме этого", "это сложно", "надо все переделать". На самом деле, не бойтесь, переделывает он далеко не все, большая часть кода у него остается в целости и сохранности (хотя и ее он тоже временами переделывает - так, чисто чтобы не залеживалась). График скорости его работы выглядит примерно так:

Обратите внимание - ни на одном из графиков я не даю ни одной цифры. Это не случайно, потому что конкретные параметры, длины пологих участков, наклоны крутых, скорость возрастания параболы у индуса - вещи не постоянные, а зависящие от самого программиста и от поставленной задачи. Неизменными остаются только общие принципы - индус осмысленен только на легкой для него задаче (приятный бонус - он сделает ее быстро), системный архитектор осилит программу любой сложности (ограничение - на любой сложности он будет ее делать долго), экстремал более-менее универсален, но за ним надо периодически следить, чтобы не увлекался, а то эти ребята иногда имеют обыкновение за деревьями не видеть леса.

Впрочем, будем реалистами - вряд ли у вас под дверью толпится полк программистов, которые только и ждут, как бы вам помочь. Скорее вам придется находить хоть какого-то и налаживать взаимодействие с ним. Не мешало бы выяснить, какой парадигмы он собирается придерживаться в этой разработке. Это, кстати, не константа. Например, автодок к "Открытому Космосу" я делал по методике экстремального программирования (там реально иначе бы не получилось никак), а вот, например, почту и хакерство к "Цене Чести" - по-индусски, потому что первую часть ТЗ я получил за две недели до игры, вторую - в ночь перед игрой, а третью - в процессе игры от мастеров, которых ловил эпизодически, в формате "кто под руку попался". Систему спасло то, что для меня она была реально несложной, но я чувствовал, что еще пять-шесть клевых фишек - и система бы пришла в состояние полного треша. А я их прикручивал постоянно, если мастера не давали задание - придумывал сам. К счастью, последнюю такую фишку я доделывал уже во время закрывающего парада.

==Взаимодействие с программистом - оценка времени==

Последний  раздел этого доклада - о том, как правильно оценивать время, взаимодействуя с разными программистами.

Во-первых, если вы не программист, не пытайтесь оценить время сами. Дать нормальную оценку может только тот, кто знает задачу и инструменты для ее решения.

Во-вторых, помните, что программисты тоже практически никогда не дают верную оценку. Скорее всего, они ее занижают, причем совершенно не со зла и не из желания обмануть. Почему так - можете почитать умные книги, типа "Мифический человеко-месяц или Как создаются программные системы" Фредерика Брукса, но можете просто поверить мне. Как минимум, программисты под сроком, когда "все будет готово" обычно подразумевают тот момент, когда отдадут свой продукт на тестирование. Учитывайте и это тоже, в крупных и сложных проектах иногда отладка и исправление багов занимает больше времени, чем непосредственно написание изначального кода. А еще - бывает какой-нибудь затык, когда должно работать - а не работает. Почти все программисты оптимистически решают, что "ну уж в этот раз такого не будет". И почти всегда обламываются.

Итак, представьте себе: вы показываете ТЗ программисту и спрашиваете, сколько времени ему потребуется, чтобы реализовать его.

Вариант первый. Индус: "Ну, это просто, здесь все понятно, здесь очевидно. Пять дней". Это означает, что индус не видит в задаче частей, которые потребовали бы от него использовать те средства среды разработки, которые ему не знакомы. Умножайте его оценку на два, десять дней - примерно столько пройдет до момента, когда индус впервые отдаст программу на тестирование.

Вариант второй. Индус: "Ну, тут я не совсем понимаю, что делать, тут надо будет спросить у кого-нибудь, а это вообще жесть какая-то". Причин две: либо он набивает себе цену (маловероятно), либо чувствует, что сложность программы соответствует той части графика, где он приближается к вертикали. Т.е. он имеет большие шансы тупо закопаться навсегда. Благодарите его и ищите другого программиста.

Вариант третий. Архитектор задает вам сотню уточняющих вопросов, надолго залипает над ТЗ, а потом безапелляционно заявляет: "Четыре месяца". Подхватываете упавшую челюсть и просите обоснования. Он с головой уходит в описание объектной модели. Тут - внимание, голактеко опасносте! Первое, что в этот момент сделают 98% мастеров - заскучают и отвлекутся. Нельзя, нельзя, нельзя! Напрягаем все силы, но слушаем его внимательно, иначе вы вряд ли поймете, где он перезаложился. Как только видим место, где он оставил очевидный "задел на будущее" - указываем ему и безжалостно режем! Нет, парень, у нас в мире есть только мужчины и женщины! Нет трансгендеров! Нет мужчин, ставших женщинами, нет женщин, ставших мужчинами, а если и есть в мире, то нет в рамках игры! Невозможно быть одновременно и мужчиной, и женщиной! Невозможно не быть одновременно ни мужчиной, ни женщиной! Оставь свои предположения на этот счет, это точно не изменится!

После нескольких часов такого хирургического вмешательства программист вытирает пот со лба и говорит: "Ну ладно, тогда не четыре месяца. Десять дней". Вот это уже ближе к истине. На два тут множить не надо, он опытный парень, уже сам предварительно умножил. Множьте на полтора - получите адекватную версию.

Наконец, вариант четвертый. Экстремал. Он читает ваше ТЗ по диагонали с пятого на десятое, а потом говорит: "Четыре дня". Погодите радоваться, четыре дня - это длина ближайшего витка спирали вплоть до очередного "Так, ну теперь тут придется все переделывать". Экстремал твердо, как "Отче Наш", знает, что вы ТЗ по ходу дела поменяете, и чаще всего это знание его не подводит. Но он понятия не имеет, сколько именно раз вы планируете это сделать в течение процесса разработки ( с Открытым Космосом это происходило явно не меньше полудюжины раз). Поэтому - Экстремал довольно точен в оценке, но он оценивает не весь проект, а только очередную итерацию техзадания, и эта оценка окажется абсолютно бесполезной уже к моменту следующего "Так, ну теперь тут переделывать надо".

Всем удачи, и успешных проектов!