Forum.iFiction.Ru

По ссылке с Хабра почитал интервью с этим автором:

Очень сильно затягивает разработку низкоуровневая часть. Когда чтоб просто нарисовать залитый полигон надо провести его триангуляцию, создать несколько массивов и скормить все это видеокарте. Это очень больно, так как знаешь, что это могло занять 4 минуты, а ты делаешь это уже 2й день.

Очень опасно, когда при разработке отталкиваешься от реализации, а не от требований. Когда начинаешь подгонять геймдизайн под то, как механика "уже работает".
Механика должна быть реализована так, чтоб человеку было проще и интересней играть, а не чтоб программисту было проще ее сделать. Точка. Никак иначе.
Желание оставить все как есть надо в себе жестоко истреблять. И когда программист говорит "так как надо сделать невозможно" то 99% что он просто ленивая свинья или плохой программист.

Nex написал:

Это индустрия развлечений. В этом кардинальное различие с разработкой любого другого софта.

А теперь вспомни, что "подсунута" тебе эта заметка была вовсе не по игростроению. Внезапно, да?
Так что это не альтернативная точка зрения, а освещение другой темы.

Однако, принцип "лучше сделать быстро, но сделать" ты продвигаешь повсеместно — и в игростроении тоже.

Возьмём из последнего:

Nex написал:

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

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

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

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

Nex написал:

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

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

Nex написал:

Olegus t.Gl. написал:

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

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

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

Nex написал:

Забивать гвозди микроскопом тяжело, медленно и неудобно. Это не значит, что нужно дорабатывать микроскоп - нужно просто взять молоток.
…
Не хотите рутинного кодинга по построению объектной модели в языке, который для этого не предназначен? Берите тот, в котором она уже есть, благо за этим далеко ходить не надо.

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

Nex написал:

QSP предназначен для написания технически несложных игр.

Что до объектной модели, то она нужна не сама по себе, а как набор определённых средств. То, что Кусп для этих средств "не предназначен" — это лишь у тебя в голове.

P.S. И ещё, Некс, — я не пишу движок. Я пишу игру, и её написание требует реализации определённых технических средств, которые, если всё сложится хорошо, я хотел бы использовать для написания следующей игры. Если ты хочешь поговорить об этом — делать это нужно в другой теме, здесь разворачивать дискуссию в этом направлении не стоит.

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

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