Руководство для начинающих создателей MMORPG

Нашел старинную статью «для чайников», переведенную с английского (R.Privantu). Написана она им была аж в 2008 году, как же давно это было. Сейчас все совсем не так, но общее представление о несусветном геморе создания новой ММО она дает до сих пор. Посвящено тем, кто рвется создать уникальную игру, но понятия не имеет и о сотой доли того, что за этим стоит. Я такой же лох во всем этом, так что естественно могут быть тупые и неправильные технически куски. Просто хотелось бы дать представление о том, что лучше делать то, что вы УЖЕ хорошо умеете, чем годами задрачивать нереальные идеи, глядя в монитор.

Эта статья описывает первые шаги в создании Вашей ММОRPG. Только создание, но никак не поддержка после старта.

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

Шаг 1. Оценка своих знаний:

Требуемые МИНИМАЛЬНЫЕ знания:

1. Знание как минимум одного языка программирования, его преимуществ и недостатков. На чем пишется, см. по вакансиям игровых студий.

2. Знание графических редакторов и особенностей компиляции графики с кодом (как минимум, векторные редакторы и\или, например, Maya). Если вы будете писать простую игру, - достаточно Flash.  

3. Определиться с сетевой библиотекой и БД (базы данных). Ну, то есть если вы не знаете, что это такое или хотя бы их варианты - то вам не сюда.  

4. Наличие сервера и понимание, что означают применительно к слову "сервер" слова  "сколько", "зачем" и "как". 

5. Иметь игровой опыт, измеряемый в годах. То есть представление о ведущих потребностях пользователей, об игровых понятиях (например, что такое интерфейс и зачем он нужен). 

6. Иметь опыт в программировании. Для примера, иметь понятие что такое платформа, многопоточность, разработка пользовательского интерфейса и т.п. 

7. Иметь представление о ключевых понятиях вне серверной части. Начиная от операционных систем и их св-в и заканчивая детальными понятиями, такими как, например, .NET Framework.

8. Иметь представление об экономической составляющей, потому что 99% тех, кто хочет сделать ММО, рассчитывают на большие прибыли. Начиная с теории получения экономической прибыли и заканчивая платежными системами в сети Интернет.

ОЧЕНЬ РЕКОМЕНДУЕТСЯ знать:

1. Клиент-серверное взаимодействие и архитектуру построения систем.

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

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

4. Защита и администрирование. DOS-атаки, читы, эмуляция, пакеты, логи, тестирование, боты и принцип их работы и т.п. Вы же не хотите, чтобы кто-то взломал Ваш сервер или дюпнул бабло, убив экономику на вторые сутки после открытия сервера?

5. Работа в команде, управление командой. Вам нужна будет команда, которой Вы сможете успешно управлять.

Шаг 2. Создание эскиза разработки

Я заметил, что много людей пишут в форумах сообщения о поиске команд для разработки MMOG. «Мы – начинающая компания/игровая студия и нам нужны 3 художника, 2 программиста, 1 музыкант и т.д. для создания инновационной, никогда ранее не существовавшей MMOG, в которой Вы будете иметь полную свободу действий и возможности изменения мира и т.п. Мы оплатим Вашу работу по окончании разработки, когда мы сделаем на этом немного денег». К сожалению, с ограниченной пропускной способностью (сетевой) Вы не сможете создать динамического мира. Если ваш сервер исчисляется несколькими гигабайтами, то вы не сможете НЕ перегружать его каждые два часа при наличии хотя бы 500 пользователей. Попытка создать что-то невозможное приводит к провалу. Правильней будет начать с малой, полностью рабочей, flash-игры. Кстати, такую игру сможет написать даже один человек, если он имеет примерное представление о том, что указано выше.

Основная архитектура:

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

1. Создание нового персонажа

2. Сохранение этого персонажа (на стороне сервера)

3. Вход в игру персонажем

4. Создать возможность общения с другими

5. Создать возможность передвигаться по миру (желательно в 3D, но в пр-пе можно пока и 2D).  

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

Если у вас уже есть опыт администрирования или создания free-сервера по любой ММО, это будет большим плюсом. Можете взять любой из готовых открытых шаблонов (любая игра, где выложен код).

Шаг 3. Безопасность

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

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

Когда происходит обнаружение хакинга, запишите это в лог: в чем суть нарушения, имя пользователя, его IP адрес, время и дата. И время от времени проверяйте этот лог. Если вы обнаружите немного нарушений от многих пользователей, то это, скорее всего, ошибка в коде клиента или проблемы с сетью. Однако, если вы обнаружите много нарушений от одного и того же пользователя или IP адреса – это показатель того, что кто-то «забавляется» с сервером, пытается найти способ взломать его.

Также, никогда не храните данные на стороне клиента. Клиент должен получать все свои данные с сервера. Другими словами, клиент никогда не должен отправлять данные, вроде следующих: «так, это список моих предметов» или «у меня сила равна 10, манны – 200 и жизни 2000 из 2000».

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

Конечно, всегда найдутся люди, которые напишут боты, радары и найдут читы и баги в любой игре. Но нужно иметь в виду то, что я написал выше, так или иначе.

Сервер должен иметь возможность следить за последними действиями каждого игрока, а каждый игрок должен иметь личный идентификатор (например, ID).

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

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

Примеры.

Возможность копирования вещей

У игроков это называется "дюп" (от английского dupe - копировать). Основная идея: с помощью ошибки в коде создается дубликат вещи. Обычно вещи являются одной из основных ценностей в MMOG. Их можно передавать, а значит, устранить последствия такой ошибки будет проблематично: игрок может создать кучу крутых вещей и раздать их остальным игрокам. Если заблокировать только этого игрока, то вещи останутся в мире и будут нарушать баланс. Если забрать все вещи этого рода у всех игроков, то они будут недовольны и могут уйти из игры.

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

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

Пример 2. В RO есть два типа торговли:

1. Обычный обмен вещами. Может совершаться между любыми игроками.
2. Создание магазина. Особый персонаж, торговец, создает лавку. Любой игрок может зайти в нее и купить вещь.

На одном из пиратских серверов была ошибка: если деньги одновременно передавать через оба типа торговли, то они копировались.

Пример 3. Сохранение данных игроков в RO происходило отдельно для игроков в случаях:

·        Выход игрока из мира.

·        После торговли.

·        Каждые 5 минут.

На одном из серверов был обнаружен баг: при перезагрузке сервера данные не сохранялись принудительно. Поэтому при объявлении о перезагрузке сервера через 5 минут игроки проделывали следующие действия:

Перезаходили в мир. Таким образом, они сбрасывали пятиминутный счетчик своего сохранения. И в следующий раз они должны были сохраниться через 5 минут, чего не происходило, так как сервер уже перезагрузился.

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

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

Результатом этого стал выброс на рынок большого количества улучшенных вещей. Что прямо повлияло на экономику и игровой баланс.

Посылка неправильных пакетов

Известно много примеров, когда посылкой пакета с некорректными данными игрок мог добиться больших благ.

Пример 1. В WoW, если в пакете использования заклинания поставить уровень заклинания 0 (а уровни считаются с 1), то для некоторых заклинаний можно было добиться моментального использования без затрат маны. На пиратских эмуляторах это точно работало. Про официальный сервер точно не скажу.

Пример 2. В LA2 на официальном сервере был баг. Если в пакете покупки вещей заменить количество вещей на "-1", то сервер забирал одну такую вещь и взамен нее выдавал 2 миллиарда денег.

Пример 3. В RO есть умение телепорта. Клиент вначале посылал пакет использования этого умения, а потом посылал пакет телепорта. После первого пакета сервер отнимал ману за телепорт. После второго - происходила сама телепортация. Однако, если послать только второй пакет, то мана не отнималась, а телепортация происходила.

Все эти проблемы достаточно простые и решаются добавлением пары строчек кода. Однако эти проблемы прошли через отдел тестирования. Все дело в том, что "простой смертный" тестер не может послать произвольный пакет.

А еще можно было сделать вот так.

Шаг 4. Создание команды

Вы не сможете все сделать в одиночку. В идеале, команда для мелкой стартовой игры должна состоять из следующих людей: 3 программиста (сервер, клиент, тестировщик – впоследствии могут перекочевать в тех.поддержку в полном составе), 4 художника (3D художник, 2D художник, аниматор, WEB-дизайнер), идеолог (тот, кто создал художественный макет и идею игры и придал ей логику и смысл), менеджер проекта (по совместительству может заниматься модерацией).   

Пояснения:

Создание 3Dmap - очень долгий процесс, и он очень важен для создания удачной игры. Желателен лидер для команды разработчиков игрового мира с дизайнерским образованием и познаниями в сфере разработки игр. Вы не можете просто взять кого угодно, чтобы они делали что угодно. Так Вы не сможете получить качественно проработанный игровой мир. А ведь именно такой Вам нужен, не так ли?

WEB-дизайнер нужен в случае, если Вы сами не сможете сделать хороший веб-дизайн, или не хотите потратить часть своего времени на разработку качественного сайта. Если ваша игра – простейшая, то он и не понадобится. А вот если в игру начнутся массовые финансовые вливания – он вам будет просто необходим, причем с познаниями в области безопасности.

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

Разработчик игровой экономики. Вы можете подумать, что это просто, и Вы сможете сделать это все самостоятельно, но фактически – это один из самых сложных вопросов. Если Ваша экономика плохо просчитана (например, вещи не сбалансированы, ресурсы на карте размещаются случайным образом и т.п.) игрокам будет скучно, или вообще на вторые сутки рухнет экономика игры, когда дроп на поляне с когтистыми гамадрилиадами 12 уровня превысит стоимость максимального сета в 100.000 раз. Внутриигровая экономика должна быть спланирована на месяцы вперед, включая шоп, если вы его планируете вводить в игру. Однажды рухнувшая, не сбалансированная экономика – это уничтожение всех игровых вещей, то есть вайп. Позвольте напомнить, что пользователи очень не любят когда удаляют их НЕ багнутые предметы.

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

Все что нужно для начала – это 1 программист и 1 художник. Если Вы программист – просто найдите художника. Если вы художник, - найдите программиста. Попросите друга или знакомого, который умеет рисовать или программировать, помочь вам и, если нужно, оплатите потом выполненную для Вас работу.

Ну что, у Вас есть идея как должна выглядеть игра. Теперь время начинать воплощать эти идеи в жизнь. Возвращаемся к 5-ти пунктам «основной архитектуры» (см. выше) и делаем это. Просто пробуем, потому что ньюансов столько, что я гарантирую отвал 95% тех, кто еще вчера жаждал написать свою ММО.

Если вы справились с задачей и У ВАС ВСЕ РАБОТАЕТ как минимум пару часов без тотальных глюков, то читаем дальше.  

Когда появился частично работающий серверный и клиентский движок (можно спереть с других проектов с открытыми кодами), и несколько скриншотов для демонстрации (или что-нибудь лучше, например, возможность игрокам войти в мир, походить и осмотреться вокруг, поговорить с другими игроками в игре), многие захотят присоединиться к Вашей команде. Желательно, пока не использовать в Вашем клиенте уникальные разработки и технологии (записать в личный блокнот и оставить, возможно на года). Просто сделать клиентское приложение - программу с открытым исходным текстом. И работать именно с ней всем тем, кого вы найдете на этом этапе. Сервер должен быть с закрытым исходным кодом (исключая тот случай, что Вы разрабатываете полностью «open-source» MMORPG).

А вот как будет выглядеть идеальная команда для проекта 3D высокого класса.

1. Графический контент и художники. Арт-директор – контроль качества и времени исполнения, большой опыт в игровых проектах и отличное управление командой. 2D художник – двухмерные персонажи, маркетинговые компании, создание дизайна сайта игры, он же часто дизайнер интерфейса и \ или концепт-художник; может выполнять задачи художника по текстурам. Концепт-художник – делает эскизы на бумаге для утверждения начальством и демонстрации инвесторам или в рекламных компаниях, это рисунки с персонажами, которые все вы видели в роликах, например; он же создает общую концепцию художественной части игры. Муви-мейкер – делает мувики по игре. 3D-модельер – костюмы, покрытие техники, модели зданий и т.п., должен знать графические 3D-редакторы, типа Maya, 3DsMax.Может выполнять функции модельера персонажей, который создает полигональные модельки чаров. Аниматор – грубо говоря, как и что движется в игре. Художник спецэффектов – вся эта поебень с яркими взрывами и ударами веслом с уроном над головой. Ведущий дизайнер – развитие основной идеи игры и контроль остальных дизайнеров. Дизайнер игровой механики – перевоплощение идей в код. Дизайнер миссий или уровней. И так далее, зависит от масштабов игры.

2. Звук. Композитор и тот, кто озвучивает диалоги как минимум.     

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

4. Разные программисты. Начиная от сервера, тех.поддержки и заканчивая сетевым программистом (поддержка скачки обновлений и подобная лабуда). 

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

6. Гейммастера; кто-то, кто разбирается с платежами; кураторы игрового сообщества; менеджера и т.п.

Дальше читайте тут.  Я просто выпилил кусок, дабы масштабность понятна была. 

Еще пара советов: не хвастайтесь (не афишируйте) Вашей игрой до тех пор, пока у Вас не будет хоть что-то для демонстрации. Одна из самых раздражающих вещей – когда новичок оставляет сообщения вроде «требуется помощь», приглашает большое количество людей в команду, рассказывает о том, какая классная игра будет. Но пройдя дальше по линкам на такой проект (обычно он располагается на бесплатном хостинге) вы увидите потрясающее меню, содержащее в себе секции вроде «Скачать», «Скриншоты», «Концепт-арт», «Форум» и пр. Вы нажимаете на ссылку «скачать», и получаете красивую картинку «в процессе разработки» (или ошибку 404 в худшем случае). Когда Вы нажимаете на ссылку «скриншотов» - получаете аналогичный результат. Если у Вас нет файлов на скачивание, не создавайте ссылку «Скачать». Если нет скриншотов – не создавайте и этот линк тоже. Лучший вариант – это не тратить свое время на создание сайта до тех пор, пока у Вас не будет готово как минимум 50% РАБОЧЕЙ болванки проекта (как кода, так и арта). Гораздо важнее отладить и трижды проверить работоспособность клиента и стабильность сервера.

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

1. Вы не можете сделать MMORPG, для этого требуется большая компания.

В то время как создание игр World of Warcraft, EverQuest, Asheron’sCall, Lineage и других - невыполнимая задача для небольших независимых команд разработчиков, создание скромной игры вполне возможно, и зависит только от уровня Вашего опыта, мотивации и свободного времени. Вам потребуется не менее 1000 часов для программирования, чтобы создать простую техническую демо-версию, и вероятно до 10-15 тысяч часов для полного завершения создания сервера и клиента. Но как руководитель команды Вы должны будете делать намного больше, чем просто программировать. Держать команду вместе, разрешать конфликты, делать публичные заявления (PR), техническая поддержка, настройка серверов, решение вопросов с блокировкой игроков, «мозговые штурмы», и т.п. будут сопровождать Вас все время. Эти заботы засосут вас полностью. Скорее всего, Вам также надо будет ходить на работу, что еще больше будет урезать время, которое можно посвятить проекту. Вам очень сильно повезет, если ни один участник команды не уйдет из нее, но если это случилось, то это может стать большой проблемой. Только представьте себе, что ваш художник уходит в середине проекта. И что еще хуже, он не оставляет права использовать его работы далее. Конечно, эта проблема может быть решена при условии наличия контракта, но искать нового художника будет утомительным занятием. Использование двух различных художественных стилей в одном проекте также будет проблемой.

2. Требуется большая сумма для поддержания серверов.

Это неправда. Я видел много выделенных серверов с ограничением в 1000 Гб/месяц за ~100 долларов/месяц. Если ваш протокол передачи данных хорошо разработан, этих 1000 Гб вполне достаточно для сервера с постоянно подключенными 1000 игроками (в среднем). Конечно, Вам может потребоваться еще один сервер для веб-сайта и клиентских файлов на скачку (скачивание файлов клиентами может серьезно увеличивать трафик, особенно если игра станет популярной). Сервер, подключенный к сети через DSL соединение, вполне может подойти вначале, пока у Вас будет в онлайне 20-30 игроков одновременно. Затем можно найти кого-нибудь, предоставляющего хостинг.

Но. Разработка AAA проекта стоит от миллиона долларов и более. Средний бюджет проекта колеблется от 18 до 24 млн. долл. Если речь идёт о продукте для одной единственной платформы, то его стоимость составит около 10 млн долл. Для российских компаний разработка среднего проекта обходится в среднем от 100 тысяч до миллиона долларов. Стоимость разработки маленьких российских проектов идет от 10 тысяч долларов. Разработку обычно финансирует издатель, хотя последнее время появляются успешные примеры финансовых вливаний из индустрий, не связанных с геймерством. Процесс разработки обычной современной игры занимает около года, для ААА-проектов может затянуться до 2-3 лет, цикл разработки обычных «казуальных» игр занимает порядка 4-6 месяцев, при том, что идет конвейерная разработка сразу 2-3 проектов. И это сроки для компаний с большим опытом на рынке игр и с опытными сотрудниками со стажем как минимум одного ходового проекта.

3. Создание MMORPG очень увлекательно.

Это неправда. Может быть, Вы считаете, что все будут с пониманием относиться к Вам, что разработчики будут жить в мире и согласии; что игроки будут помогать и терпеть недочеты; что Вы сможете сделать инновационные квесты. Но разработчики могут стать амбициозными и хитрыми. А игроки могут быть раздражающими или баловаться загаживанием вашего проекта. Даже если это полностью бесплатная игра, они все равно найдут повод написать или сделать вам гадость. И самое неприятное – люди часто жалуются на совершенно противоположные вещи. Воинам не нравится то, что очень долгое время нужно набирать новый уровень, в то время как торговцы будут разочарованы в том, что воины получают много денег с трофеев. Если Вы уменьшите выпадающие из монстров трофеи, некоторые люди начнут угрожать своим уходом из игры. Если увеличите – те же люди будут недовольны тем, что теперь даже новички могут легко делать деньги. Но оставлять все как есть – это не лучшая идея. Здесь нужно использовать новые идеи и улучшения. Если Вы решили изменить что-либо, например, добавили новые проблемы для тех, кто производит предметы, некоторые скажут что это слишком сложно. Если Вы этого не сделаете – они скажут что это очень просто или скучно. Вы должны помнить, что большинство игроков обычно ничего не говорят и полностью удовлетворены всем, в то время как некоторая часть будет постоянно жаловаться.

4. Экономику в MMORPG очень сложно сбалансировать.

Да, это гораздо сложнее, чем разработать ее дизайн. Например, в одиночной игре Вы можете постепенно улучшать оружие, так что игрок постепенно продвигаясь вперед, может получать лучшее снаряжение, при этом бросать (или продавать) старое. В многопользовательской игре существует миллион взаимосвязей покупок и продаж, дропа и заточки и т.п. Разработка экономики заслуживает написания собственной статьи. Вам будет нужен кто-то, кто УЖЕ имел с этим дело.

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