Figma. Геймдизайн. Прототип поведения существ.

ScorpioT1000, я не то, чтобы в сайте ориентируюсь и знаю не все правила. Чтобы случайно не отправить контент куда не нужно - добавил его к себе в блог. Но теперь буду знать куда выкладывать, спасибо.

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

nazarpunk, если ты программист, но тебе нужно объяснять алгоритм для такой реализации, то, возможно, ты не программист а коддер?

PS - самый простой способ - брать случайную точку в прямоугольнике до тех пор, пока её дистанция до цели не будет удовлетворять условию.

Cancel,
Вот хоть где-то используется разделение на "кодеров" и программистов?

KaneThaumaturge, надеюсь, мой ответ не приведёт к раздуванию диспута. Но на вопрос я отвечу.

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

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

Кстати, книги по софтскилам тоже существуют.

Cancel:

Как только ты начинаешь программировать - ты занимаешься программированием.

nazarpunk, в твоём понимании проектировка не является частью программирования?

Cancel, проектировка это просто написание плана того, как ты будешь писать код. Тобишь программировать.

nazarpunk, "как ты будешь писать код"

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

KaneThaumaturge Могу уточнить, что имеется ввиду практика, а не теория.
Это практика, а не теория. Лиды, к примеру, редко кодят, они в основном занимаются построением программной архитектуры. Или этим занимается отдельный человек, отвечающий за архитектуру.

Интересно знать больше - могу порекомендовать книгу "Совершенный код". С. Макконелла.
Вот на какие этапы он делит процесс конструирования ПО

1. определение и отладка
2. выработка требований
3. создание плана конструирования
4. разработка архитектуры ПО, или высокоуровневое проектирование
5. детальное проектирование
6. кодирование и отладка (как раз процесс написание кода)
7. блочное тестирование
8. интеграционное тестирование
9. интеграция
10. тестирование системы
11. корректирующее сопровождение

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

Если ты работаешь один, то скорее всего проектировка у тебя происходит в голове в процессе написания кода. Таким образом ты на коддинг тратишь 99% времени, а остальные пункты проходят на фоне.
Это приемлемо, когда ты работаешь над небольшими проектами. Так, в этой же книге приводится пример разницы строительства будки и возведения небоскрёба.
При строительстве будки ты не станешь тратить 90% времени на проектирование. Скорее всего ты сразу возьмёшь инструменты и материалы и начнёшь мастерить будку, проводя какие-то вычисления и планирование в процессе её строительства.
Но если вы строите небоскрёб - иерархия усложняется, возрастает необходимость работы с требованиями, составление и мониторинг архитектуры, цена за ошибку слишком высока, и каждый должен следовать своей части работы.

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

Минихоливар, начатый здесь, описывается синдромом "Why Isn't Sam Coding Abything" когда ошибочно предполагают, что программирование = коддинг.

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

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

Cancel, Cancel:

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

nazarpunk, софистика