Гдд что это такое
Что такое ГТД на автомобиль и двигатель
Многим водителям приходилось сталкиваться с ГТД, но немногие обращают внимание на эту аббревиатуру. Еще меньшее число водителей интересуются значением этого понятия.
А зря, ведь на практике столкнуться с ГТД может каждый и нужно иметь хоть малейшее представление об этом явлении.
Часто такая аббревиатура всплывает в профессиональных кругах. Даже при покупке автомобиля можно неожиданно столкнуться с загадочным набором этих букв. С чем же мы имеем дело?
Как расшифровывается ГТД и что это такое
Знакомство нужно начать с расшифровки аббревиатуры ГТД. Ведь наверняка есть немало водителей, которым не до конца понятна суть нашего разговора. Под этими тремя буквами подразумевается грузовая таможенная декларация. Этот документ требуется для пересечения границы и въезда в другое государство. Не особо стало понятно, что такое ГТД на машину, потому разбираемся дальше в этом понятии.
В этом документе указывается информация о водителе и перевозимом грузе. Заполненный бланк подаётся в определённые контролирующие и проверяющие органы. Оформляется такая декларация в ряде случаев, которые мы рассмотрим немного позже. Благодаря этому документу таможенные органы проводят учёт и контроль экспортных и импортных товаров.
Каждая декларация имеет уникальный номер. Он складывается не из случайного набора чисел. Номер разделён на 4 части при помощи слэша. Каждая часть несёт в себе определённый смысл:
А что же собой представляет ГДТ на мотор или кузов автомобиля? И вновь возникает много вопросов, а ситуация по-прежнему остаётся непонятной.
ГТД на двигатель, о чём нужно знать
Силовой агрегат любого автомобиля также является товаром, как и все другие. Следовательно, при экспорте/импорте силового агрегата также является обязательным оформление ГТД на двигатель. При этом неважно о каком агрегате идёт речь: новом или бывшем в употреблении. В любом случае требуется оформлять ГТД. Этот документ является подтверждением страны-происхождения двигателя и факта прохождения таможенного контроля.
Без ГТД на двигатель невозможно будет оформить замену силового агрегата на авто. К ГТД на двигатель по правилам должна прилагаться обязательная документация. Только в этом случае возможно проведение регистрации нового агрегата.
Через границу России может ввозиться кузов автомобиля. При такой ситуации также является обязательным оформление ГТД на кузов ТС. Часто автомобиль ввозится по запчастям, а затем собирается заново. Очень важно при покупке автомобиля бывшего в употреблении проверять соответствие номеров на кузове, силовом агрегате и ПТС.
Заполнение ГТД
Ответственно и серьёзно нужно отнестись к процессу заполнения грузовой таможенной декларации. Документ должен содержать подробную информацию о водителе и транспортируемом грузе. Заполнение этого заявления осуществляется на двух бланках: ТД1 и 2. Первый бланк считается основным листом, второй выполняет роль добавочного.
ТД1 состоит из нескольких листов с самокопирующимися свойствами:
При перевозке через госграницу груза, состоящего из нескольких наименований, на помощь приходит ТД2. Без этого дополнения ГТД не используется.
ГТД на транспортное средство
Отдельного внимания заслуживает ГТД на автомобиль, которая оформляется при ввозе/вывозе ТС. Чаще всего, конечно, оформление грузовой декларации требуется при покупке автомобиля в другой стране. Этот документ в обязательном порядке предоставляется в органы ГИБДД для оформления автомобиля и постановки его на учёт.
Оформлением грузовой таможенной декларации занимается распорядитель груза. Дальше следует процесс заверения документа, который ложится на плечи инспектора таможенной службы. В случае покупки автомобиля юридическим лицом продавец выдаёт покупателю копию ГТД, предварительно заверенную. От покупателя требуется внимательность и дотошность. Он должен тщательно проверить VIN-код с автомобиля и сверить его с данными из ПТС. Любая ошибка и неточность станут серьёзной проблемой и не позволят поставить автомобиль на учёт в родной стране.
При покупке физлицом автомобиля из-за границы в добавок к ГТД и ПТС добавляется приходный ордер. Этот документ, как и два остальных, обязательно должен предъявляться органам таможни и сотрудникам ГИБДД.
Ситуации, не требующие заполнения ГТД
Грузовая таможенная декларация — это особый транспортный документ, который состоит из нескольких листов. В обязательном порядке к этому документу прилагается ДТС. За этой аббревиатурой скрывается декларация таможенной стоимости. Это приложение закрепляется за тем грузом, который облагается НДС, акцизом и таможенными пошлинами.
Если рассматривать автомобиль в качестве груза, то к нему должна прилагаться ДТС. Но имеются некоторые исключения, которые прописаны в законодательных актах. Список таких исключений выглядит следующим образом:
Грузовая таможенная декларация — важная составляющая для ввоза и вывоза товаров. К ней нужно относиться серьёзно и ответственно подходить к оформлению необходимой документации, чтобы в дальнейшем не возникало проблем. Правильное оформление, составление и заполнение грузовой таможенной декларации — основа для международных транспортных отношений.
Лайфхаки ГДД
Сергей Гимельрейх, гейм-дизайнер, основатель творческого пространства ИНДИКАТОР, делится лайфхаками создания гейм-дизайн документации.
Многие гейм-дизайнеры постоянно задают вопросы и спорят на тему “правильной гейм-дизайнерской документации” (ГДД), и хотя мы уже не раз публиковали статьи, посвящённые теме, ещё раз пройтись по теме будет не лишним. Мы постарались собрать лучшие советы по ведению гейм-дизайнерской документации, и привести пример описания условной фичи, как отдельной статьи ГДД. Надеюсь, этот материал будет полезным и станет основой стандартизации гейм-дизайнерской документации.
СОВЕТ №1: Структурируй.
Пример структурирования разделов страницы типового описания игровой системы в ГДД:
СОВЕТ №2: Оставляй перекрёстные ссылки.
Не ленись оставлять перекрёстные ссылки в документе на другие страницы описания других игровых систем, если в этом есть необходимость.
СОВЕТ №3: Выделяй эффекты, звуки и анимации.
Обозначай Эффекты, Звуки и Анимации в описании фичи отдельными выделенными блоками. Это упрощает формирование задач художниками, специалистам по эффектам, саунд-дизайнерам и аниматорам.
СОВЕТ №4: Используй цветовую кодировку времени изменения.
Есть положительный опыт использования цветовой кодировки в описании фичи для обозначения:
СОВЕТ №5: Оставляй шпаргалки.
Оставляй подробные примечания к ячейкам таблицы. Каждый раз, когда тебе кажется, что тут и так все понятно, подумай о тех, кто будет читать таблицу в твоё отсутствие.
СОВЕТ №6: Заведи базу знаний.
Вести общую трелло-доску на весь отдел гейм-дизайна. Есть разные колонки, с концептами новых игр, новых фич, подборки визуальных референсов, интересные статьи и видео про игры или гейм-дизайн, которые нашли и решили что они полезные.
Отдельно вести доску с лайфхаками внутри проекта. Там содержатся всякие подсказки как выполнять какие-то редкие задачи, или как выполнять какие-то рутинные задачи быстрее. Доска ведется в виде FAQ. Заголовки — вопросы, а в описании подробный ответ.
Например тебе нужно заменить содержимое одного лутбокса в игре. Последний раз это делали 3 месяца назад, да ещё и не ты. Заходишь в шпаргалку отдела и видишь кем-то оставленную заметку как это сделать буквально в пару кликов. Благодаришь всех богов за лучшую команду на свете.
СОВЕТ №7: Избегай дублирования.
Максимально избегать дублирования информации. Любая информация должна быть только в одном месте в ГДД, все остальные места должны либо подхватывать из первоисточника, либо ссылаться на него. Если пренебрегать этим правилом, рано или поздно кто-то обновит диздок в одном месте и забудет про другое, а еще через пол года команда начнёт путаться в разных данных.
Если избежать дублирования никак не возможно, необходимо выбрать первоисточник и во всех второстепенных местах указать ссылку на первоисточник. Чтобы было понятно какой документ главнее, в случае расхождений.
СОВЕТ №8: Помечай настраиваемые константы и переменные.
Всегда стоит помечать параметры и константы, которые должны быть вынесены в настроечные таблицы проекта. Если есть хотя бы малейший шанс, что цифру в диздоке понадобится в будущем поменять (то есть практически всегда) нужно отмечать цветом или символом или как угодно еще, что это параметр, который может меняться. Иначе есть риск, что цифру захардкодят. И это будет вина ГД.
СОВЕТ №9: Используй изображения и анимации.
Не лениться делать гифки и тратить время на оформление ТЗ. Иногда 3 гифки в ТЗ на анимацию вместо тысячи слов, как рафаэлло!
СОВЕТ №10: Не перекладывай ответственность на исполнителя фичи.
Не указывайте в диз.доке варианты выбора на усмотрение исполнителя. В стиле «тут можно сделать любого цвета, какого захочется, неважно» или «строка может быть длиной от 30 до 400 символов».
Исполнитель, берущий в руки тех.документ пришел не ребусы отгадывать и не принимать решения за гейм-дизайнера, а узнать что конкретно нужно сделать. «Сколько вешать в граммах». Обычно такие свободные формулировки гейм-дизайнер оставляет от того, что сам не знает как нужно сделать. В этом нет ничего страшного, знать все на свете не возможно. Но правильней будет проконсультироваться с теми, кто знает и в ГДД указать уже точные данные для исполнителя.
То же самое касается и призывов к обсуждению в ГДД, в стиле «как думаешь, 5 строк рейтинга в окне будет нормально?» Обсудите этот вопрос заранее в чате, а в диз.док запиши уже конкретные данные. Когда кто-то откроет документ через несколько месяцев, он будет совсем не в восторге от того, что ему придется читать еще и какие-то ветки решенных комментариев, чтобы докопаться до нужных данных.
СОВЕТ №11: Обозначай исключения.
Если есть особое требование к функциональной логике системы, которое обозначает исключительные случаи, лучше эту информацию отдельно выделить для разработчика.
СОВЕТ №12: Пиши кратко и ёмко.
Текст описания логики работы системы в фиче должен быть максимально ёмким и концентрированным, при этом раскрывать все аспекты системы, чтобы программист и другие специалисты могли в полной мере реализовать функционал.
ПРИМЕР ОПИСАНИЯ ФИЧИ
ВЫБОР СТАРТОВОГО КОСТЮМА
Автор: Василий Пупкин [ссылка на профиль с данными для связи]
Дата обновления: DD.MM.YYYY
Цель: Стимулирование первого платежа. Создание привязки к личной собственности. Возврат игрока к следующей сессии.
Описание
Игрок после нескольких диалогов стартового сценария попадает в форму выбора начального костюма для своего персонажа. Можно выбрать один костюм из предложенных вариантов (не менее 2-х), при этом костюмы могут быть бесплатными или продаваться за софт- или хард-валюту.
Логика работы
Игрок по специальной команде из стартового сценария игры переходит в форму выбора костюмов.
Форма получает данные о списке доступных костюмов на выбор с сервера.
Список костюмов настраивается гейм-дизайнером в отдельной таблице (описание в разделе Настройки).
В форме игроку на выбор предлагается несколько костюмов (не менее 2-х). Костюмы могут быть платными (за хард- или софт-валюту) или бесплатными.
Выбирать костюмы можно листая влево-вправо посредством тапа на кнопки-стрелочки на краях экрана или свайпом в соответствующую сторону. Выбор зациклен по карусельному типу.
Если игрок на экране просмотра костюма не совершает никаких действий в течение N секунд, появляется выноска с комментарием NPC, который ”говорит” фразу, привязанную к конкретному костюму. Тап по выноске или смена костюма автоматически закрывают подсказку.
Если в настройках костюма нет ссылки на комментарий, выноска не появляется.
Выбор костюма производится тапом на кнопку под ним.
Если костюм стоит хард- или софт-валюты, происходит списание валюты с счета игрока, зачисление всех предметов костюма в инвентарь игрока, затем происходит демонстрации костюма на персонаже в анимации. Далее — выход из формы в сценарий.
В следующем диалоге сценария после формы выбора костюма, персонаж игрока появляется уже в новом выбранном костюме.
ИСКЛЮЧЕНИЕ:
Если не хватает валюты, происходит автоматический переход игрока на покупку недостающего количества валюты за реал. После покупки валюты происходит зачисление на счёт, отъем недостающего количества для покупки сета с счета игрока и финальный эффект выбора костюма (см.описание интерфейса).
Интерфейс и эффекты
Форма полноэкранная (экран в портретной ориентации), с настраиваемым фоном.
Форма появляется через FADE-эффект при переходе на неё.
В центре располагается персонаж в текущем предлагаемым костюмом.
У персонажа включена анимация idle.
Слева и справа расположены кнопки-стрелки, для смены костюма.
Лучше кнопки расположить в нижней части формы, чтобы удобно было до них дотягиваться пальцем.
В нижней части экрана, под куклой персонажа, расположена кнопка “ВЫБРАТЬ” или “КУПИТЬ ЗА …”. Тап по этой кнопке является подтверждением выбора костюма.
Подсказки в процессе листания
Игроку могут отображаться подсказки после перелистывания на новый костюм спустя N секунд (настраивается), которые отображаются в виде «подвешенного» бабла с текстом и пиктограммой NPC.
Координаты бабла и идентификатор пиктограммы настраиваются.
Контроль
Листать костюмы можно также свайпами влево-вправо.
Смена костюмов карусельного типа,- при достижении последнего костюма, если пользователь листает дальше, ему показывается первый и так по кругу (в обе стороны).
При тапе на кнопку “ВЫБРАТЬ” или “КУПИТЬ ЗА …” отображается эффект вспышки, воспроизводится анимация куклы для подиума, исчезают контролы, вместо кнопок в нижней части экрана появляется мигающая надпись “НАЖМИТЕ ДЛЯ ПРОДОЛЖЕНИЯ”.
ЭФФЕКТ:
Яркая вспышка по аналогии фотовспышки на подиуме. В этот момент убираются контролы (стрелки и кнопка выбора) и появляется мерцающая надпись TAP TO CONTINUE. В момент вспышки меняется костюм на кукле и включается эффектная анимация. В качестве остаточного эффекта осыпается что-то вроде конфетти поверх одетой в новый костюм куклы.
После тапа в любом месте экрана — экран засветляется(FADE через белое), происходит переход в сценарный диалог после формы.
Затронет системы
Аналитика
| Событие | Описание | Кастомные параметры события | Тип параметра |
| set_form_open | Форма выбора сета открылась | — | bool |
| set_form_select_set | Выбранный игроком сет | set_ID |
Настройки
Команда в сценарии:
Таблица настроек сетов костюмов:
Надеюсь, эта подборка будет полезна для вас.
Благодарности тем, кто помог с подборкой:
Как написать дизайн-документ игры
Советы новичкам от опытного геймдизайнера
Прежде, чем начать рассказывать правила составления ГДД, давайте определимся, кто же такой геймдизайнер и какова его роль в команде. Ближайший аналог геймдизайнера в искусстве — это режиссёр. Он не играет в фильме, не занимается светом и декорациями и даже не держит камеру, но при этом именно он решает, как должен выглядеть фильм, чтобы он доносил зрителю те ощущения, которые хочет режиссёр. Также и геймдизайнер очень часто не умеет рисовать и программировать, но обязан уметь вызывать у игрока нужные ощущения.
Поэтому его можно назвать мозгом команды, тем, кто всегда контролирует то, что делают все остальные. Даёт задания и принимает работу. Поэтому главное умение геймдизайнера — находить общий язык со всеми в команде и делать так, чтобы они производили именно то, что есть в его голове. Поэтому в идеале нужно, чтобы каждый проект вёл один хороший специалист. О том, насколько трудно такого найти — это уже совсем другая тема. Просто давайте держать в голове, что эта статья — про хорошего геймдизайнера или того, кто хочет им стать.
Вы, наверное, заметили, что среди обязанностей геймдизайнера я не упомянул ГДД. Потому что в идеальном сферическом мире он не нужен. Там геймдизайнер всегда держит в голове описания всех фич, никогда не болеет, не увольняется и ему не нужно ни перед кем отчитываться. Геймдизайнерский документ игры — это вспомогательный документ. Страховка студии от пропажи геймдизайнера, памятка о том, что он хотел сделать, ведь разработка может подчас растягиваться во времени по не зависящим от него причинам, и памятка для специалистов о том, что они должны сделать, если вдруг отвлеклись.
Тут важно отдельно выделить человеческий фактор. Даже при самом идеально написанном техническом задании (далее, ТЗ) будут те, кто его поймёт не так. Кто-то неправильно интерпретирует очевидный вам оборот. Кто-то не будет знать термина или будет знать его омоним (которые в индустрии встречаются довольно часто). Кто-то просто пропустит строчку, читая по диагонали. Действовать с такими людьми жёстко — с высокой вероятностью угробить собственную компанию.
Некоторые, желая сэкономить, нанимают геймдизайнера только для написания документации — результат обычно плачевный. Фильмы не снимают без режиссёра, даже когда из Marvel уволила гениального Эдгара Райта и он оставил после себя максимально полные раскадровки, они всё равно наняли другого человека, чтобы тот доделал фильм. Хотя раскадровки Райта, конечно, лезут из всех щелей и теоретически можно было бы работать по ним.
Теперь о том, как писать сам ГДД. Крупные компании используют для этого сервисы вроде Confluence, но я, поработав в них, нахожу их не особо удобными, по сравнению с самым доступным способом ведения документации — Google Docs. Легко заполнять, легко делиться, легко ориентироваться, да ещё и бесплатно. Если вы беспокоитесь за безопасность, всегда есть возможность сделать корпоративный аккаунт Gmail и тогда никто за пределами студии не зайдёт в вашу документацию.
Следующий большой вопрос — ГДД в одном файле, или как набор ТЗ. Скажу прямо — оба варианта имеют право на жизнь. Первый вариант имеет смысл использовать если у вас небольшой проект вроде match-3 или подобной игры. ГДД до 20 страниц объективно удобнее хранить одним куском. Если же у вас есть гора различных режимов или контента, например миллиард различных танков для WoT, или подробное описание каждого уровня для шутера, то лучше это всё распихать по разным документам, оставив главному лишь структуру.
Также это удобно для выдачи задач: кинул ссылку на конкретный документ — и не паришься, разъясняя, где искать. Но, повторюсь, очень часто удобнее хранить всё в одном файле так как многие проекты не отличаются размером.
В малом проекте с этим всё просто — оно делается штатными средствами документов. Или не делается вообще, что тоже бывает. Если же у вас крупный проект, да ещё и с иерархией, то в главном файле лучше расписать всю его структуру со ссылками на все остальные файлы. Если у вас в проекте есть иерархия, то не стоит ложить ссылку на самое дальнее ТЗ только в промежуточном.
В мой первый месяц работы у меня случилась неприятность: я выложил спецификации по самолётам для World of Warplanes в один подраздел (за давностью лет не помню уже в какой), а программисты искали его в соседнем (художники, кстати, не промахивались). Сначала я хотел продублировать ссылки, чтобы их можно было найти везде, но потом я понял, что правильнее просто выложить все ссылки в виде структуры прямо в главном документе. Тогда сразу появляется понимание структуры проекта и не нужно делать лишних кликов для перехода на нужную страницу.
Место для краткого описания игры. Фактически краткая выжимка концепт-документа: название, технологии, платформы, аудитория. Это информация не для вас и не для вашей команды, а для продюсеров, которые, открывая ваш документ, должны мгновенно понять, что у них в руках. И заодно понять, не лажанулись ли вы с позиционированием и своими возможностями.
Необходимо выделить для себя, какая часть игры у вас является базовой, то есть, в чём игрок будет проводить больше всего времени. Например, в нашумевшей Gardenscapes игрок в основном играет в match-3, хоть это и не подчёркивается. Там создатели делают упор на обустройство сада, а match-3 как бы второстепенное занятие, служащее для зарабатывания звёзд. Но на самом деле в этом разделе нужно описывать именно его.
На этом этапе часто встаёт вопрос: как структурировать написанное так, чтобы программисту его было легко читать. Перепробовав множество разных вариантов, я пришел к выводу, что лучше всего поступить так: в каждом разделе использовать свою нумерацию с иерархией. То есть, пишете утверждение. Под следующим номером другое утверждение. Если у вас есть уточнение или дополнение к основному утверждению, то переходите на один уровень вглубь и пишите там. Например: 1. Персонаж двигается в изометрии при помощи WASD. 1.1 Если игрок направляет персонажа в стену, тот останавливается при столкновении со стеной. 2. При нажатии на ЛКМ игрок стреляет. И так далее.
Важно описать всё не красиво, а точно, не упустив ни малейшего аспекта. Баг, сделанный программистом, чинится им же в ограниченное время. Дизайнерский баг (непродуманный момент) может разом перечеркнуть многие месяцы работы команды. «Не ошибается тот, кто ничего не делает» — отличная фраза для такой ситуации, потому что не реально предусмотреть всё, но одно дело не продумать один экран, а совсем другое — ошибка в базовой механике, из-за которой всё неиграбельно.
В первые три-четыре года работы геймдизайнером и в первые три-четыре месяца на новом рабочем месте вы обязаны подружиться с лидом программистов, чтобы скидывать ему свеженаписанные ТЗ с вопросом: «Нормально?». Это значительно повышает их качество и снижает время, потраченное на разбирательства.
Head-up display — вся информация, которую видит человек, играя в шутер от первого лица. Здоровье, патроны, маркеры на экране и тому подобное. В других жанрах его аналог можно называть по-разному, но в любом случае это то, что видит игрок во время базового геймплея. Это одна из самых важных вещей в игре — игрок должен понимать то, во что играет, но при этом оно не должно отвлекать его от геймплея.
На самом деле искусство создания хорошего HUD — это огромная наука, специалистов в которой очень мало. Лучше всего составлять его совместно с арт лидом и быть готовым, что переделывать его наверняка придётся.
Этот раздел статьи я хочу начать с рассказа о том, что такое мокап. Или варфрейм. В индустрии очень часто одни и те же сущности в разных студиях называются по-разному и если у вас что-то из того, что я называю в статье, называли по-другому — это проблема отсутствия единого профессионального словаря. Итак, это — схематичный набросок, сделанный в графическом редакторе человеком, максимально далёким от рисования. Здесь не стоит задача сделать красиво, здесь стоит задача сделать понятно. Чтобы художник без лишних вопросов гармонично расставил кнопки и всё остальное.
Лично я для этого использую программу Pencil Project, но вы вольны выбирать всё, что угодно. Хоть карандашом на бумаге рисовать и фотографировать. Вместо картинок — прямоугольники, кружочки, стрелки. Минимализм.
Теперь о том, что этими самыми программами мы будем рисовать. Начать лучше всего со схемы экранов. Возьмите все ваши экраны и окна и разложите на экране. Проведите стрелочки: откуда куда игрок может переходить. Это своего рода интерфейсное оглавление, которое поможет собирать проект.
Когда художник отрисует это окно, рекомендую наложить эти же кружочки на его рисунок и подменить его в ГДД. Это поддерживает актуальность и понятность, особенно если в процессе отрисовки что-то изменилось, например, положение кнопок.
Дальше мы просто бьём проект на мелкие составляющие и описываем каждый в своём разделе. Туториал, инвентарь, диалоги, глобальная карта, прокачка — всё, что у вас есть. Описывается всё так же, как и базовый геймплей. К каждой из фич в раздел стоит запихнуть мокап того, что с ней связано.
В конце ГДД можно вставить несколько разделов, которые являются очень полезными для некоторых жанров.
Балансировка — описание того способа, которым гд будет балансировать игру. Нужен практически для всех игр, особенно f2p. Оптимальным вариантом для меня является xml-файл, который конвертится и заливается по специальному адресу. Потенциально ужасный вариант — веб-интерфейс, в котором каждый параметр нужно вводить ручками.
Админка — возможность банить и поощрять пользователей через веб-интерфейс. Необходима для он-лайн игр.
Сбор статистики — жизненно необходимая вещь для f2p. Перечислить все точки сбора статистики и формат её получения.
Minimum Value Product или MVP — описание минимально играбельной версии, которую можно выложить на общий доступ, чтобы проверить, насколько ваш базовый геймплей востребован. Необходимо если вы делаете f2p и придумали оригинальный геймплей.
Прежде всего — описаний анимаций. Это самая частая ошибка новичков. Называйте действия конкретно: «Пушка стреляет». Да, у вас мультяшный стиль и пушка перед выстрелом надувается, будто тужится — всё это не важно программисту, а аниматор лучше вас знает особенности движка и как сделать всё атмосферно. А пожелания лучше передавать ему лично.
Референсов. Картинки делают файлы неподъёмно большими, а те в свою очередь уменьшают их размер, поэтому их лучше заливать в папку на дропбокс, свн или гугл диск. Отдельную папку для каждой сущности, естественно. Видео лучше заливать на ютуб и давать прямые ссылки.
Текстов. Выделите под них отдельный файл, желательно xml, чтобы программисты легко могли подтянуть его прямо в игру. А потом его же будете локализовывать.
Литературных описаний — никто не оценит.
После того, как вы написали все ТЗ и лид программистов уверенно сказал «Нормально», вы переходите на главную часть работы геймдизайнера — коммуникации. Если эта статья вам понравится, то я напишу ещё одну — как правильно выдавать работу разным специалистам и принимать результаты.
Не забывайте, что всё, описанное в этой статье — не нормативы (хотя если вы заберёте их себе и сделаете нормативами — я против не буду), а результат моей многолетней работы на позиции геймдизайнера. Никто не мешает вам сделать лучше.