Мастерская Ярослава Кравцова

График A/B-тестирования моей игры Planet Settlers. Идея была проверить как влияет добавление в туториал озвученных реплик с дополнительными подсказками. Так как были жалобы от игроков на ИИ-озвучку, да и команда разработки устала слышать эти реплики на каждом тесте. На графике Treatment - игроки, у которых эти реплики были отключены. Control - контрольная группа, у которой реплики были на месте. В итоге, на графике видно, что игроки, получающие голосовые подсказки, остаются в игре заметно дольше.

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

Рост графика объясняется изменением аудитории. Сначала была больше доля игроков, пришедших по рекламе. Затем увеличилась доля пришедших по системе рекомендаций, то есть более целевой аудитории.

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

Отсюда типичные ошибки геймдизайна:
* Правила меняются. Игрок не осваивает правила. Правила используются один раз и не повторяются.
* Циклы не имеют на выходе ресурсов. Ресурсы одно цикла не стыкуются с ресурсами другого цикла. Есть ресурсы, которые создаются циклами, но нет циклов, которые бы их использовали.
* Игроки игнорируют определенный ресурс и связанные с ним циклы, потому что сочли его бесполезным.
* Отсутствие выборов, все циклы следуют строго друг за другом. Представьте себе шахматы, где каждый ход у вас только один вариант как ходить.
* Слишком много правил, непредсказуемость результатов выборов, много рандома - игрок не может построить ментальную модель игры. А без модели игрок не может планировать и получать удовольствие, когда план сработал.

Разобрав свою игру на такие кусочки, можно найти слабые места и возможности по улучшению. Посмотрите на свою игру как круговорот ресурсов через циклы.

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

1. Любая игра - это набор правил.
2. Игрок изучает правила, а затем многократно применяет их.
3. Каждое применение правила - это цикл, который что-то требует на входе и что-то дает на выходе.
4. Игра состоит из системы различных циклов, где ресурс на выходе одного цикла используется как ресурс на входе другого цикла.
5. Из этой системы есть как минимум один выход, завершающий игру. Обычно выходов два: победа и поражение.
6. Знания игрока о возможных выходах из игры формирует у него шкалу ценностей ресурсов, выделяя те, которые приближают к желаемому исходу.
7. После того, как игрок изучил правила игры и понял как циклы перерабатывают ресурсы, он построит ментальную модель как двигаться к желаемому исходу и как получить больше ценных ресурсов, которые этому помогут.
8. Чтобы игроку было интересно, построение ментальной модели не должно быть очевидным, когда последовательность циклов жестко задана. У игрока должен быть выбор циклов (как выбор хода в шахматах).

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

На примере футбола:
1. Мяч перемещается ударом ноги. Попадание мяча в ворота - гол.
2. Игрок многократно бьет по мячу, чтобы двигать его в сторону ворот противника.
3. Упрощенно, каждый удар по мячу требует, чтобы игрок был в позиции рядом с мячом, а на выходе получаем, что мяч меняет свою позицию на поле.
4. Цикл удара по мячу переходит в цикл мяч попал в ворота.
5. Есть цикл времени и когда он заканчивается, то срабатывают выходы победы и поражения, в зависимости от количества голов.
6. У игрока есть ценности: гол в ворота противника - хорошо, гол в свои ворота - плохо, владение мячом - хорошо, когда мячом управляет противник - плохо.
7. Игрок строит ментальную модель как ему довести мяч до ворот противника или не дать противнику довести мяч до своих ворот.
8. У игрока есть выбор куда бить по мячу - стараться самому довести мяч или передать пас товарищу по команде. А если не бить по мячу, то какую позицию занять на карте с учетом возможного развития событий, чтобы помочь команде забить гол или защитить свои ворота.

Теперь на упрощенном примере Warcraft III:
1. Игрок может строить здания, нанимать юнитов, давать юнитам задачи.
2. Игрок строит базу из множества зданий, нанимает много рабочих и солдат, первым выдает задачу на сбор ресурсов, а вторым на сражение с солдатами противника.
3. Строительство зданий требует дерево и золото. Найм юнитов требует наличие нужных зданий и золото.
4. Рабочие дают ресурсы. За ресурсы игрок строит здания. За здания и ресурсы нанимает новые юниты.
5. Если все юниты и все здания игрока будут уничтожены - это поражение. Если игрок уничтожит всех юнитов и все здания противника - это победа.
6. Иметь много ресурсов - хорошо. Иметь много юнитов - хорошо. Когда у врага много юнитов - печаль.
7. Игрок налаживает экономику, развивая базу, чтобы иметь больше ресурсов и построить большую армию, которая победит армию противника.
8. У игрока есть выбор отправить рабочего за деревом или золотом. Или выбор создать еще рабочего, чтобы было больше ресурсов, или создать солдата, чтобы защитить базу от нападения. А также выбор тратить ресурсы на постройку зданий или на найм юнитов.

Записал процесс вайбкодинга в Roblox с помощью Claude Opus в формате as is. Решил попробовать сделать гонки и что из этого вышло. Без предварительной подготовки и тестов. Хотел показать как нейронка размышляет, а заодно получился пример, показывающий сильные и слабые стороны такого подхода. Если что, я не спец по вайбкоду и возможно что-то делаю очевидно неправильно. Так или иначе, но за 39 минут у меня так и не получилось достичь желаемого результата. При этом последние 20 минут к результату не приближали.
https://www.youtube.com/watch?v=2JBt9on4u1g

Провел сегодня небольшое исследование на тему игр, где есть отношения родитель-ребенок (как роли, не обязательно прямое родство). Всё благодаря хайпу вокруг игры Pragmata, которая зацепила в геймерах родительский нерв. Решил посмотреть где ещё есть арки с развитием отношений между родителем и ребенком. С разбиением на пол ребенка и пол родителя. При помощи твиттера удалось наскрести несколько подходящих игр.

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

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

Приведу пример двух моих сообщений, которые я отправлял авторам проектов. С минимальной редактурой - убрал NDA-шные детали.

Сообщение №1

Итак, про документацию. В первую очередь нужен конецпт-документ. Это ещё не диздок, но по нему понятны основные моменты про игру.

Например, в нем нужны ответы на следующие вопросы:

1. Краткое описание игры. Так, чтобы в этом описании было понятно и про геймплей, и про сеттинг, и про жанр.

2. Список референсов. С указанием на что именно референс. Например, сеттинг из книг, визуал из фильма, геймплей из вот этой игры на роблоксе.

3. Заранее определите на какую аудиторию ориентируетесь. Все таки игры для 7-10 лет - это одна история, а для 15-18 лет - совсем другая. То есть попробуйте описать примерный портрет пользователя.

4. Также важно отметить на какие платформы ориентируетесь. Сразу скажу, что надо поддерживать мобилки. Поэтому вариант делать игру только на ПК - не вариант.

5. Про геймплей также отдельно надо описать core loop.

6. Сколько игроков на сервере

7. Key selling points

Сообщение №2

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

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

Для начала нужен документ, в котором будет:
1. Название проекта (рабочее), таргет по платформам, таргет на аудиторию. Про аудиторию надо больше понимания, чем просто возраст.

2. Краткое описание проекта

3. Референсные игры, с описанием что именно в них берется за референс.

4. Если основная фишка игры - это ####. Нужно описать немного как эта фича должна работать. Возможно какие-то референсы именно на неё.

5. После этого можно писать core loop геймплея, то есть как игрок будет взаимодействовать с главной фишкой.

6. Design Pillars

7. Обозначить на чем будет строится монетизация проекта.

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

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

1.4. Из диздока можно сделать фичелист. Каждую фичу можно оценить по требуемым ресурсам (два месяца программистов, неделя UX дизайнера, пять минут геймдизайнера). Сложив оценки фичей получаем оценку времени разработки проекта. Если помножить на зарплаты команды и другие расходы, то можно получить бюджет проекта. Хоба! Если не влезаем в бюджет, сроки, команду, то пересматриваем фичи. Понятное дело, что оценки грубые, обязательно ошибетесь, что-то забудете. Ошибиться в 2-4 раза не так страшно, как ошибиться в 20 раз, если не сделать этот этап. Впрочем, всё равно закладывайте буферы. Сколько именно закладывать поймете с опытом и пониманием команды. Для первого раза начните с умножения всех сроков в два раза. Не факт, что поможет, но хотя бы снизит вероятность остаться без денег с игрой на 60% готовности.

1.5. Вот только тут, спустя столько бумажной работы, открываем редактор и начинаем собирать прототип. Или прототипы. На этом этапе я вижу следующие цели:
1.5.а. Собрать прототип геймплея, чтобы как можно скорее пощупать геймплей и понять фан или не фан. Если не фан, то тут же принять меры, чтобы стало фан.
1.5.б. Возможно в игре запланированы какие-то крутые технические фичи, которые команда раньше не делала. Имеет смысл сделать прототип, который подтвердит, что команда может делать такие фичи. Например, команда никогда не делала онлайн игры с высокой нагрузкой. Конечно, тут надо не забыть про пункт 1.0. Но после этого имеет смысл сделать прототип, на котором погонять высокую нагрузку. При этом не обязательно прямо здесь и сейчас сшивать это с механиками базового геймплея. Вполне нормально, когда у вас много независимых прототипов, каждый из которых решает свою задачу. Прототип по арту тоже можно сделать.

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

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

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

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

Про следующие этапы смотрите в следующих сериях...

Когда я только пришел в геймдев, то где-то откуда-то знал, что есть такие этапы разработки игры как демо, альфа, бета, релиз. Без каких-то внятных объяснений чем они отличаются друг от друга. Потом ещё узнал про прототипы и вертикальный срез. Сейчас, если погуглить, то можно найти описание 5 этапов, 6 этапов или даже 7 этапов разработки. Как видите, какого-то консенсуса тут нет. И как можно догадаться, сейчас я вывалю свои этапы. Зачем? Потому что главные проблемы в разработке случаются из-за нарушения последовательности этапов. Когда какие-то этапы упускаются или когда какие-то работы происходят не в свой этап.

Для начала разобьем всю эту вакханалию на ключевые фазы:
1. Препродакшн (Pre-production), когда от идеи сделать игру доходом со состояния готовности её делать.
2. Продакшн. Собственно, когда вся команда пыхтит, делая игру.
3. Релиз. Вся эта суета по подготовке к запуску, запуску и последующему хаосу.
4. Пост-релиз. Это может быть 10 лет оперирования игры, а может быть выпуск небольшого патча и дальнейшее забвение.

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

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

1.2. Прежде чем уходить в подробный диздок, следует написать концепт-документ. Короткий документ без воды и мелких деталей, по которому можно понять о чем вообще должна быть игра. Обязательно в письменном виде и доступный для всей команды. Именно тут идея игры опускается на бумагу и начинаются первые конфликты, когда оказывается, что в мыслях всё было как-то легче и красивей, чем в буквах. Главное помнить, что исправить ошибку на этом этапе - это переписать текст, но если её оставить, то исправление на следующих этапах может занимать несколько человекомесяцев. И самое главное - не пишите в стиле маркетингового булшита, словно вы кому-то что-то впаривайте красивыми лозунгами. Это документ для команды, а не для покупателей. Пишите просто и ясно.

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

Есть у меня гилти плеже просить новые версии нейронок написать мне генератор локаций (террейн + объекты). После чего бегаю по локации без идей что делать дальше. Для большой сложной игры ресурсов нет - занят на других проектах. Для маленькой игры нет яркой идеи что за геймплей можно наложить на такие локации.

Epic Games сократили одним днем тысячу человек, о чем написали на своем сайте. Для справки, они уже сокращали 870 человек в сентябре 2023 года, что тогда составляло 16% от компании. Простая математика говорит, что если с тех пор они не нанимали в больших количествах, то текущее сокращение составляет почти четверть компании. Это очень серьезно.

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

А также напоминание, что сейчас не простые времена в индустрии, раз даже у таких гигантов тряска.

В одном закрытом чатике сформулировал свой подход к геймдев образованию:

Мы помогаем людям попасть в геймдев, то есть в кровавую баню 😈

Вторая terra incognita в геймдеве для меня - это крипто-игры. При том, что несколько лет назад я сам влезал в эту тему и оставил вот такой артефакт. Я немного понимаю технологию и в целом согласен с идеей, что можно раздвинуть рамки игровых экономик, прав собственности на игровые предметы, финансовых взаимодействий между игроками. Это могло бы значительно изменить мир игр.

Вот только одна беда: чем больше в игре возможности заработать на ней, тем больше в ней желающих заработать, но меньше тех, кто просто хочет играть ради фана. А если нет игроков, то это уже не геймдев.

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

Опять же, го в комментарии, если я не прав и есть пруфы.

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

Я вижу мобильный рынок так:
- Игры доступны через штучное количество маркетплейсов (AppStore, Google Market, китайские магазы, рустор)

- Все эти магазины по UX калька друг с друга, сам UX как придумали сто лет, так никакой эволюции не было

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

- Значит остается только покупать трафик. При этом на самом маркетплейсе его купить нельзя. Зато можно купить через показ рекламы в чужих играх.

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

- Вот и выходит, что миллиарды долларов мобильного рынка - это разработчики, которые по кругу покупают друг у друга рекламу.

- При этом на рынке есть несколько мегалодонов (Supercell, Playrix, Azur Games, G5, SayGames и другие), научившихся выживать в этой кровавой бане и даже делать профит. А ещё есть сотни тысяч мелких разработчиков, которые не понятно на что надеются, но продолжают тысячами в день вываливать новые игры в стор, без каких-либо шансов на выживание.

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

Случаи успеха, вроде Loom Games, не аргумент. Во-первых, это единичные случаи, а не общее состояние индустрии. Во-вторых, не забываем, что за красивыми цифрами популярности игры и ежедневного дохода стоят огромные цифры расходов на маркетинг, которые мы не знаем.

А ещё можно вернутся к теме, что из каждого игрока надо выжимать максимум профита, что сильно бьет по геймдизайну. Вплоть до того, что на мобильной платформе невозможны многие игровые жанры по причине убыточности. Хотя железо в телефонах давно позволяет делать очень сложные и красивые игры.

Го в комменты объяснять где я не прав!

Не зовите меня на свой проект, если у вас нет таких багов.

We’re excited to announce a collaboration with the Serbian Games Association in Belgrade 🇷🇸

Many years For The Win! conference has been uniting game developers from around the Balkans in Serbia. With a strong and active community, what can be a better place to spark a new hub for international collaboration?

This September, we’re joining our forces in organizing the conference to provide meaningful connections, business deals, and the gamedev showcase.

🖇 Mark your calendars: September 29-30. More details and tickets are coming soon.

Ой, ёй! Тут коллаб года. В конце сентября DevGAMM и Сербская игровая ассоциация проведут совместный ивент в Белграде!! 🔥😱🥳

В начале игры Inside есть отличный пример игрового баланса, от которого мурашки, не смотря на всю простоту реализации. Сцена всего на 20 секунд, за которые игрок сначала проваливается эмоционально вниз (я в воде замедлен/уязвим, меня заметили, на меня несется очень быстрая собака, мне от неё не убежать) и затем резко выныривает по эмоциями вверх (я выбрался из воды и могу бежать, я прыгнул в последний момент). То есть игрока нехило так качнули на эмоциональных качелях. При этом технически у нас есть лишь игрок, который может делать только одно действие - двигаться вправо, и собака, по сути проигрывающая заранее заготовленную анимацию. Дальше лишь школьная математика про скорости движения и точку встречи мальчика А с пёсиком Б. Ставим в метре до этой точки спасительный прыжок и вот они мурашки.

Выложили фото с недавно прошедшего G5 Games Meetup в Белграде. С одной стороны, хочется поблагодарить организаторов за выбор фотографа, который сделал много хороших портретов. С другой стороны, негодую, что фото выложено просто свалкой на сайте, вместо того, чтобы залить их в соцсети. Чтобы все участники ивента могли бы друг друга отмечать на снимках, а затем узнавать кто есть кто и френдиться. Это простой, но очень важный инструмент для нетворкинга на митапе и после него.

Раньше я видел сложность в обучении разработки игр в том, что всё постоянно меняется. Только объяснишь студентам что какая кнопка в Unity делает, как выходит новая версия, где совсем другие кнопки. Отсюда главная сложность, что преподавать должны практикующие специалисты, отслеживающие все эти изменения, а не преподаватели по методичке, как это происходит с обычным образованием в школах.

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

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

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

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