Koladik, моя ошибка. И это не духота. Спасибо, исправлю.

nazarpunk, учесть-то это можно, но как результаты помогут статье объяснить значимость разброса урона?
Для простоты и скорости расчётов броню и типы урона лучше учитывать не на этапе нанесения урона, а на этапе определения живучести.
Представим, что ТИП_УРОНА_А наносит 50% урона ТИПУ_БРОНИ_Б
Представим, что за счёт защиты цель поглощает ещё 50% урона.
Представим, что у цели 30 здоровья.

Мы эти 30 здоровья трансформируем в = 30 / 0.5 / 0.5 = 120 ед. выживаемости, и уже на её основе делаем дальнейшие расчёты.
Например при атаке 2d6 юнит с 120 выживаемости умрёт в среднем за 17.6 ударов, при следующем распределении:

rsfghd,

Мне очень жаль это слышать. Желаю, чтобы у тебя всё наладилось. Простите за оффтоп.
PS способность шикарная

nazarpunk:

Увидел свою ошибку и починил, спасибо -)
Забыл сбросить значение поля

nazarpunk:

Первый скрин - вызов функции создания тексттега
Второй скрин - функция создания тексттега
Третий скрин - удаление тексттега

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

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

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

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

"По сопровождению и помощи с нашей стороны сейчас обсуждаем"
Отлично! Даже если ответ будет отрицательным, спасибо что вынесли на обсуждение -)

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

nazarpunk, софистика

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

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

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

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

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

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

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

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

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

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

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

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