Войти
Игровая индустрияФорумУправление

Как выглядит идеальное/оптимальное ТЗ внутри одной компании?

Страницы: 1 2 Следующая »
#0
11:18, 15 янв 2019

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

Собственно вопрос: как долго выглядеть оптимальное/идеальное ТЗ?
Что в нём должно быть обязательным?
Что часто бывает, но по факту не нужно и просто загромождает лишнее?
Какие форматы, шаблоны лучше всего подходят?
Нужно ли описывать всю предельно подробно, либо оставить свободу творчества, мол, исполнитель сам часто лучше знает как лучше сделать.

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

#1
11:46, 15 янв 2019

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

#2
15:09, 15 янв 2019

/A\
> В идеале лучше видео и скриншоты чем куча текста.
Ну, скриншоты и тем более видео, для того, что ещё не готово тяжело представить. Если игра только разрабатывается где видео или скриншоты взять?
Разве что набросать схемку где какая кнопка должна быть на экране, если речь об интерфейсе.

/A\
> Все что может быть изменено позднее пометить
Это само собой. Без этого никак, согласен на все 100%

А нужно ли описывать какие классы (применительно к ООП) делать и в целом архитектуру кода описывать?

#3
15:14, 15 янв 2019

Dmitrrr
> А нужно ли описывать какие классы (применительно к ООП) делать и в целом архитектуру кода описывать?
Если исполнитель мидл/джун, то можно. В остальном случае максимум интерфейс классов которыми ты будешь пользоваться в коде/скриптах/редакторе.

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

#4
18:40, 15 янв 2019

Вот так:

#5
21:53, 15 янв 2019

/A\
> В остальном случае максимум интерфейс классов которыми ты будешь пользоваться в
> коде/скриптах/редакторе.
Можешь пример привести?
/A\
> попробуй пойми чего они хотят на самом деле
Да, есть такие, что не умеют донести свою мысль. Или в лирику ударятся "стрелковая башня должна затруднять прохождение врагов ведя по ним непрерывный огонь", или напишут что-то совсем краткое вроде "башня должна стрелять по врагам и наносить им урон". И додумывай как хочешь.

jaguard
> Вот так:
Т.е. никак?

#6
22:10, 15 янв 2019

Dmitrrr
> Можешь пример привести?
Ну смотря к чему вопрос был:
> А нужно ли описывать какие классы (применительно к ООП) делать и в целом архитектуру кода описывать?
Если тебе нужно чтоб в редакторы был объект с такими-то свойствами, то ты так и пишешь, то что он в коде состоит из 10 классов ты даже не узнаешь. То же самое и в скриптах.
Но я боюсь даже представить что мне геймдизайнер будет говорить как строить архитектуру кода))

#7
11:28, 16 янв 2019

Вопроса как такового собственно нет. Просто захотелось узнать "у кого как принято".
Что нужно задавать в ТЗ программисту, что нет.

Ну вот, к примеру, о стрельбе тех же башен. Для простоты примера будетм считать, что башни автоматические типа ТауэрДефенса.
Сказать "сделай, чтобы башни сами стреляли по врагам" явно мало.
Как минимум нужно включить в ТЗ:
1. Дать общее описание процесса (Башня стреляет сама без участия игрока. Стреляет как только противник пересёк радиус дальности действия башни. Из башни должно вылететь что-то, долететь до ближайшего врага и нанести ему урон в момент попадания. Скорость движения и манёвры цели не учитываются)
2. Параметры для настройки (скорострельность, дальность, скорость снаряда, урон, шанс критического удара, меткость, пригодные цели). С их первоначальными значениями и формулами их обработки.
3. Что заложить в визуализацию (изменение внешнего вида башни во время выстрела, внешний вид снаряда, отображение взрыва при попадании). При этом форматы моделей/текстур/картинок, видимо, лучше отдать на откуп программисту - он лучше знает, какой формат выбрать ,чтобы было и красиво и не тормозило.

На первый взгляд всё важное названо. Но только на первый взгляд.
4. Т.к. игра онлайн, для защиты от читеров лучше хранить все характеристики на сервере. Видимо, это тоже лучше указать, чтобы неопытный программист не оставил это на откуп клиенту игры.
5. За этим сразу возникает вопрос, как и когда передавать все нужные данные с клиента на сервер и обратно. Делать ли это при каждом выстреле или реже? Как вообще максимально синхронизировать клиент и сервер, уменьшить трафик, задержки, лаги, но обеспечить защиту от взлома? Это вопросы касаются гейм-дизайнера, или это всё на совести программиста?
6. Ещё надо как-то увязать стрельбу с остальной игрой. Например, когда начинается стрельба, когда она заканчивается. Тут на вскидку может быть 2 подхода:
- игра по определённой логике/тригерам переключает состояния башни "стреляет/не стреляет",
- игра отдаёт приказ на каждый выстрел.
Вряд ли гейм-дизайнеру будет важно каким из этих вариантов будет реализовано, но знать какой вариант выбран, ему не повредит.
7. Выстрел должен нанести урон. Значит процедура выстрела должна как-то оповестить другие элементы игры (счётчик очков, счётчик хп и прочие) о том, что юниту нанесён урон. Нужно ли об этом писать в ТЗ или это "и так понятно". А ведь тут те же вопросы возникнут - на сервере это обрабатывать, или на клиенте, или как-то совместно.
8. Для отладки игры могут пригодится логи. Значит в ТЗ можно(нужно?) указать "по каждому выстрелу заносит в лог время, цель, урон, крит, промах"
9. Может что-то ещё важное я упустил?

#8
12:52, 16 янв 2019

Dmitrrr
Этак и программист не нужен :)

2,3 пункты. Ну и может 8 нужно указать явно, раз такое требование имеется. Остальное сугубо технические вопросы. Их должен решать разработчик. Понятно, что если мы говорим о ТЗ, которое дает лид-программер, одному из своих тиммейтов-разработчиков, то там и больше пунктов будет. Но когда геймдиз берет на себя роль лида программистов, это тож бред, по-моему.

#9
16:36, 16 янв 2019

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

И т.д. и т.п. В идеале должен быть расписан каждый малейший шаг.

#10
3:55, 22 янв 2019

Dmitrrr
> Что нужно задавать в ТЗ программисту
по ТЗ работают только кодеры, реальному программисту ТЗ не нужно, как минимум в том смысле как многие понимают .. всех программистов учат составлять ТЗ со слов эксперта в соответствующей области. Основной совет, отсюда, если пишите о стрельбе башен, представьте себе, что вы генерал в этом мире, и вам нужно провести курс молодого бойца .. а это значит писать только предметным языком, не пробйте думать за программиста и писать на его языке, все равно у вас не получится, а его это будет раздражать .. а вот толковое описание 'генерала' как вести бой даст ему куда больше

#11
8:29, 22 янв 2019

Dmitrrr
> 9. Может что-то ещё важное я упустил?
  Я бы начал бы с разработки архитектуры системы,
продумал бы какая часть программы что делает. Далее
продетализировал бы их по максимуму.

  Чтобы получилась примерно вот такая схема:
Init | Как выглядит идеальное/оптимальное ТЗ внутри одной компании?

А потом уже можно начинать писать код.

#12
19:06, 22 янв 2019

Dmitrrr
> Тема в первую очередь о ТЗ, которые дают гейм-дизайнеры программистам.
А дворники у Вас программистов за пивом еще не гоняют?

#13
20:44, 22 янв 2019

whitewolf1
> Чтобы получилась примерно вот такая схема:
Боюсь, что такую схему никто кроме программистов не осилит)) И вряд ли даже поймёт.


gudleifr
> А дворники у Вас программистов за пивом еще не гоняют?
За флудом в другой раздел форума, пожалуйста.

#14
21:04, 22 янв 2019

Dmitrrr
> За флудом в другой раздел форума, пожалуйста.
Уговорили, отнес в "Перлы".

Страницы: 1 2 Следующая »
Игровая индустрияФорумУправление

Тема в архиве.