По отдельности их подключить можно, а как насчет всех вместе одновременно? Ну, знаете, такая вот погодная станция, с DHT22, датчиком давления, газовым датчиком MG811. Результаты — на дисплей и на сервер для хранения. И пара тройка кнопок на корпусе. А в перспективе желательно еще туда же поставить DS3231 на случай долгой работы без интернета и карту флеш-памяти, чтобы сохранять результаты. Arduino позволяет легко масштабировать проекты не упираясь в необходимость экономить каждый байт памяти и каждый пин. И меня удивляет, почему вы, как поборник дорогих и громоздких комплексных решений не видите очевидных плюсов такой интеграции.
Ссылки не содержат промо-кода, так что мне нет никакой прямой выгоды от их размещения. Закупаюсь я в основном, на Ali, поскольку в российских магазинах часто какая-то негуманная наценка, причем на тот же самый товар. В тексте есть по одной ссылке на Tindie, и Olimex.
Если вы знаете какие-то хорошие магазины, которые можете порекомендовать — напишите, пожалуйста, список. Я посмотрю и добавлю апдейтом.
Все верно, это китайская UNO R3 MEGA328P, стоимостью около 3$. Насчет поиска — тут все не так просто. Например, по запросу «блок питания 3.3В» первой ссылкой идет Чип и Дип, с блоком питания за полторы тысячи рублей. А на Ali поиск затруднен тем, что релеватность невысока и по тому же запросу про «power supply 3.3» вылезает все подряд, включая источники тока с плавающим напряжением в 3-12В.
Почему глюк? Вы же сами захватили коммуникацию по uart и не вернули ее на место.
Чтобы не доводить дело до перепрошивки, можно делать это не сразу, а по команде с сервера. Или через выполнение другого файла с задержкой в секунду (успеете стереть). В моем случае ESP при включении качает с сервера файл с lua и запускает его, что позволяет, к примеру, одним копированием перевести его в telnet-сервер, чтобы посмотреть что там и как.
Об этом подробно будет вторая часть статьи. Но если кратко, то можно как просто связать TX-RX и тогда все работает отлично даже на скорости в 115200, так и через SoftwareSerial, но тогда придется снизить скорость до 9600.
Само общение идет как-то так:
uart.write(0,"ARD:gettemp\n"); -- так отправляется запрос
uart.on("data", "\n",
function(data)
-- тут разбираются ответы
_,_,humidity,temp = data:find("OK: ([%d.]+),([%d.]+)");
end, 0);
"\n" означает, что функция будет вызвана как только встретится символ "\n", можно вместо этого указать, например, минимальное количество.
Я присматривался к 12-E, насторожило, что у него PCB-антенна и нет гнезда под внешнюю антенну. Как у него вообще с качеством связи?
Arduino выступает в роли исполнительного модуля. На него цепляется самое разное железо. Например, если нужно считать показания с трех датчиков (температура-влажность, давление, уровень CO2) и вывести результаты на двухстрочный LCD-экран, то как сделать это одним ESP?
Насчет DNS.
tcpdump ничего такого не показал
18:36:55.097770 IP 192.168.10.36.4096 > 192.168.10.1.53: 0+ A? esp. (21)
18:36:55.097770 IP 192.168.10.36.4096 > 192.168.10.1.53: 0+ A? esp. (21)
18:36:55.097855 IP 192.168.10.1.53 > 192.168.10.36.4096: 0* 1/0/0 A 192.168.10.1 (37)
18:36:55.097862 IP 192.168.10.1.53 > 192.168.10.36.4096: 0* 1/0/0 A 192.168.10.1 (37)
18:41:56.111751 IP 192.168.10.36.4096 > 192.168.10.1.53: 1+ A? api.pushingbox.com. (36)
18:41:56.111751 IP 192.168.10.36.4096 > 192.168.10.1.53: 1+ A? api.pushingbox.com. (36)
18:41:56.111845 IP 192.168.10.1.53 > 192.168.10.36.4096: 1 1/0/0 A 213.186.33.19 (52)
18:41:56.111853 IP 192.168.10.1.53 > 192.168.10.36.4096: 1 1/0/0 A 213.186.33.19 (52)
Оба запроса пришли на мой DNS-сервер (192.168.10.1) и он же ответил на них.
Интересно, почему отправляется сразу по два запроса?
Единственный непонятный мне запрос, это вот этот:
18:36:54.966762 IP 192.168.10.36 > 224.0.0.1: igmp v2 report 224.0.0.1
Для каждой комбинации значений параметров вам придется заново проводить затратные численные расчеты
Почему же они затратные? Одна симуляция считается сотые доли секунды. И множество симуляций нужно только если есть разброс параметров из-за рандома, в т.ч. ведущего к ветвлению, который ваша система вообще не может учитывать.
А теперь, пожалуйста, выразите эту мысль на математическом языке, а то непонятно, куда надо подставлять параметры и как вычислять результат.
Без проблем, но баш на баш — представьте сначала, скажем, итоговую систему уравнений для размена при котором каждый отряд имеет всего пять параметров: очки здоровья (на юнит), урон (на юнит), броня отряда (вычитается из всего входящего урона за раунд), шанс крита (шанс нанести двойной урон в раунд, применяется до брони). Да, кстати, не забудьте обосновать, что непрерывные функции подходят для вычисления заведомо дискретных разменов.
Это настолько затратно, что заставляет искать более оптимальные решения.
Почему вы считаете, что это затратно?
сможете ли вы при мне за 5 минут написать программу симуляции сражения в тех конфигурациях, что были рассмотрены в статье.
А я это уже сделал, когда захотел проверить выводы насчет потерь.
Пример
use strict;
for (my $pp = 0; $pp < 100000; $pp+=100) {
my $L1 = 100000;
my $L2 = $pp;
my $k = 0.01;
while ($L1 > 0 && $L2 > 0) {
my $LN1 = $L1 - $L2 * $k;
my $LN2 = $L2 - $L1 * $k;
$L1 = int($LN1);
$L2 = int($LN2);
}
print "$pp $L1\n";
}
А вот так выглядит график построенный по выводимым данным:
Обратите внимание на характерную точку 80,60 (0.8, 0.6 в вашем случае).
Ну и, чтобы дважды не вставать, про время:
$ time perl a.pl > data
real 0m0.033s
А это один поток на половине ядра шестиядерного процессора 2011г., работающего на пониженной частоте. И язык — интерпретатор.
Заодно покажете, каким именно образом в моем подходе резко нарастает сложность при добавлении особенностей.
Выше я предложил пример для решения. Всего пять параметров. Мне нетрудно добавить их в симуляцию и построить графики, включая трехмерные, по любым соотношениям любых параметров.
Этот спор сродни тому, как если бы вы утверждали, что ни к чему учиться брать интегралы аналитически, так как всегда возможно посчитать их численно с любой требуемой точностью.
Вообще-то нет. Я утверждаю, что ни к чему учиться брать интегралы в конкретном случае, типа работы портного, который может просто взять сантиметр и измерить весьма сложную и нелинейную фигуру клиента. В задачах, где вычисление одной точки без оптимизации занимает дни, а порой месяцы — безусловно нужна аналитика. Но геймдизайн к таким не относится.
Что происходит в других точках, где функция не вычислялась — вы не знаете. Как она ведет себя за пределами того интервала, в котором строился график — вы не знаете.
Мы изначально рассматриваем строго определенный отрезок, а именно — потери отряда. Они определены от нуля до 100 процентов. Ниже нуля они быть не могут, выше 100% — тоже. Так какое мне дело до вида функции вне рассматриваемых рамок?
Я ответил, что вопрос «быстрой оценки взаимной силы армий» вы оставили без рассмотрения, а на него надо ответить. Каким образом, зная параметры вида «сколько нужно юнитов А чтобы уничтожить тысячу юнитов Б», вы быстро оцените взаимную силу армий?
Так же, как и оценка по среднему, только берется сумма оценок взаимодействия каждого отряда с каждым.
Если итог всех этих транзакций, рандомов мер и контрмер можно выразить в простом виде — то это разве плохо?
А с чего вы взяли, что это возможно? Ваш пример с термодинамикой забавен. Ну да, в идеальном цилиндре, с идеально измеряемыми параметрами системы все просто и модель более-менее соответствует реальности. А теперь представьте, что у вас не цилиндр, а штук сто сообщающихся сосудов, с разной теплопроводностью, часть из которых при разной температуре становится упругой и может менять объем, а часть оборудована автоматическими клапанами, срабатывающими при определенных условиях, некоторые их них даже стравливают часть газа наружу, а в некоторых газ дополнительно охлаждается до состояния жидкости или подогревается до состояния плазмы. Как вы, вооруженные самым передовым знанием, что pV=NRT, сможете определить параметры системы на выходе? При этом сделать тысячу замеров результата работы этой системы сможет даже лаборант.
Зачем бороться с системой уравнений, если я ее уже решил? В статье приведен ответ, выраженный в простых формулах (6), (7), (11). Геймдизайнеру что, сложнее вычислить квадратный корень, чем проводить полномасштабную детальную симуляцию?
Вы решили задачу об обмене уроном между всего лишь двумя отрядами без каких-либо особенностей. Для ГД это что-то уровня «Hello world!», а «полноценная симуляция» в рамках решенной вами «задачи», это пять минут работы программиста-новичка. Только вот если потребуется добавить особенностей — это будут все те же пять минут, а у вас сложность резко нарастает. Кроме того, в самой игре обмен будет идти точно так же, как в симуляции, собственно, обычно симуляция и делается с использованием модуля для боевки. Это гарантирует отсутствие ошибок, включая накапливающиеся ошибки из-за отсутствия дискретности у вашей модели. Ну, а про использование любимого метода всех ГД — разброса параметров с помощью всемогущего рандома — даже как-то уже упоминать неудобно.
Полагаю, что предлагаемый вами метод полезен общего развития, чтобы ГД примерно представляли как проходят размены в простейших случаях. Но никакого практического смысла он не имеет.
Легко перепутать, например, экспоненту с гиперболой.
Если есть такие опасения, то можно по графику воссоздать функцию.
Вы же должны подставлять измеренные вами экспериментально параметры в какие-то формулы?
Это легко автоматизируемый процесс. К примеру, редактор после изменения изменении параметров может проводить симуляции и составлять таблицу значений. После чего изменять, а в том числе и добавлять различные особенности и новые виды войск сможет кто угодно. А в вашем случае геймдизайнер обречен на постоянную борьбу с системой уравнений.
В том-то и смысл данной статьи и подобных ей исследований, что результаты будут верны для широкого круга систем
Да, но по принципу «сферического коня в вакууме» — т.е. ничего конкретно применимого. Ну нет игровых систем, основанных только на простейшем размене с плавным падением численности. Везде транзакции, рандом, кучи коэффициентов, мер и контрмер. Иначе, какой интерес?
Степенной коэффициент k — это как? От чего он зависит по степенному закону? И почему именно степенному? Ведь подобные предположения надо обосновывать.
Работа модификаторов может зависеть от численности нелинейно. К примеру, отряд может иметь дополнительно шанс критического урона, зависящий прямо (или обратно, берсерки, например) от соотношения оставшейся численности отряда к максимальному значению. В случае очень больших значений размена (кстати, в играх обычно соотношение атаки к защите что-то типа 10-25%, т.е. все заканчивается куда быстрее) начинает играть роль неодновременность транзакций (бонус первого удара за засаду на местности, позволяющей делать засады). Или отряд может некоторое время поглощать урон не теряя численности (разнообразные виды защиты).
Не в один день Москва строилась. Мой подход идет от простого к сложному. Со временем, если будет вдохновение, буду усложнять модель.
Я всячески желаю удачи, поскольку если вы сможете довести идею до уровня конечного приложения, способного к анализу по указанным параметрам — это будет чудесно. Но при этом я полагаю, что вряд ли хотя бы один геймдизайнер из тысячи будет сам составлять и решать систему уравнений, хотя бы в силу того, что большинство из них испытывают головную боль даже от элементарных операций с вероятностями.
Это экспоненты, логарифмы, гиперболы или, может быть, полиномы? Никак не определите. А знание вида функций важно для интуитивного понимания изучаемой системы.
Так для этого же и существуют графики, разве нет? Кроме того, все-таки обычно геймдизайнеры создают свою систему, а не изучают какую-то чужую и примерно представляют как именно она себя ведет.
С такими затратными численными расчетами ваш бот просто не сможет работать в реальном времени.
А боту будет достаточно и десятка симуляций, чтобы более-менее достоверно предсказать результат поединка. Но есть способы предварительно упростить вычисления. Например, заранее составляется таблица соотношений размена юнитов в боях друг с другом. Условно, сколько нужно юнитов А, чтобы уничтожить тысячу юнитов Б. Затем по ней быстро оценивается взаимная сила армий. В особо примитивных случаях все вообще сводится к вычислению условной средней силы каждого юнита и сравнению суммы этих параметров, если расхождение в нужных рамках — тогда уже симуляция.
Боюсь, вы мало имели дела с математикой, если вам формулы из статьи кажутся зубодробительными!
Боюсь, вы мало имели дела со стратегическими играми, если представляете себе сведение всех условий (тип местности, броня, выучка и т.д.) к одному линейному коэффициенту k. Он в лучшем случае — степенной. Кроме того, зачастую юниты в стратегических играх обладают лимитированным количеством дополнительных возможностей — способностями к разовому исцелению раненых (вариант: вызов подкрепления), к нанесению резкого (burst) урона с последующим бездействием или без такового, к временному контролю отрядов противника (suppression, cc) и так далее. Именно эти способности требуют наибольшего внимания от ГД, поскольку именно в них таятся опасности критического дисбаланса — как вы все это будете учитывать?
Одна из первых браузерных стратегических игр — Archmage. Появилась аж в 1998г. Три типа юнитов: наземные, летающие и стрелки. Около сотни разных видов юнитов с десятком параметров и несколькими видами атак у каждого, более полусотни боевых заклинаний поддержки и атаки, герои возглавляющие отряды и меняющие их параметры.
Можно взять более поздние игры, там добавляется еще и позиционирование, понятия «подавления» и «навязывания» боя, «прикрытие» (дополнительная атака стрелков прикрывающих указанный отряд), дальность атаки и многое другое.
Мне кажется, что вашу схему можно использовать только если специально под нее создавать дизайн боевки, ограничивая все нелинейности и отрезая все возможные ветвления.
По моему опыту, проблема с транспортом решается и другими путями. Кто-то снимает квартиру поближе к работе. Кто-то меняет место работы. Кто-то договаривается на частичную или полную удаленку. Из-за пробок и проблем с парковкой в мегаполисах общественный транспорт порой оказывается быстрее автомобиля. В общественном транспорте можно дремать или читать. Кроме того, автомобиль сам по себе является мощным источником проблем, рисков и, как следствие, стресса.
А после тридцати я вообще перешел на альтернативный транспорт (ролики и самокат в теплое время года, пешком — зимой) — около 14 км. каждый день, это с одной стороны решило проблему с необходимыми физ. нагрузками при сидячем образе жизни, а с другой оказалось удобным способом приводить мысли в порядок до и после рабочего дня.
Конечно есть люди, которым нравится водить автомобиль, в смысле — нравится сам процесс, но, как мне кажется, их очень немного.
Почему же «все тлен»? Мне вот нравится работать в хорошей группе. При этом область задачи почти не важна, важно лишь, чтобы работа шла без очевидной халтуры и без самодурства. А некоторым коллегам нравится изучать все новое — им вообще безразличен исход проекта, они удовлетворяют свое любопытство за деньги работодателя к взаимной выгоде. И никаких депрессий и стресса.
Насчет квартиры и прочего — есть у меня знакомая, которой нравится улучшать жилищные условия и покупать новые машины раз в 3-4 года. Она еще до обвала доллара смогла добраться до ежемесячного дохода в 200к рублей (на те времена около $7к). Увы, нервозность, депрессии, склонность к истерикам и все прочие признаки нервного истощения и переутомления были ее постоянными спутниками. Я уважаю ее выбор, но сам так жить не хочу и не буду.
1. Большая з/п. Новичковая мотивация. Через некоторое время оказалось, что тратить деньги банально не на что — мне не интересны машины, яхты и золотые унитазы. Мне не нужна эксклюзивная и дорогая еда, в том числе и по врачебным рекомендациям. Мое хобби стоит недорого. Я с легкостью укладываюсь в 500$ в месяц, при том, что с легкость могу претендовать за з/п от 2500$, а если подпишусь на руководящую должность, то и от $4k. В итоге, за год я обеспечу себя еще на годы вперед. Когда денег скопилось какое-то неприличное количество, я традиционно вложился в недвижимость и теперь, как представитель мелкой буржуазии могу вообще не работать до конца жизни. Так на кой мне повышение зарплаты, если избавиться от установки «надо зарабатывать больше, потому что это — показатель успеха»?
2. Больше времени. Есть такая шутка, что одна сигарета сокращает жизнь на пять минут, а рабочий день — на 8 часов.
3. Более интересные задачи — это нонсенс. Чем выше профессиональный уровень, тем меньше остается интересных задач в своей области, потому что все вокруг превращается в боян и примитив. Один из вариантов выхода написали в соседней ветке комментариев — регулярная смена области профессиональной деятельности. У меня есть коллега, который раз в два года меняет язык разработки, а раз в шесть-восемь лет — область. У меня есть другой коллега, который радостно хватается за любой новый фреймворк или язык — сейчас вот он фанатеет по Свифту, например. Оба они оптимистичны, бодры и им нравится жизнь.
По-моему, основная проблема программистов в том, что профессиональная деформация начинает сказываться на самоанализе и самодебаггинге. Т.е. программисты довольно быстро доходят до внутреннего осознания бессмысленности большей части мотиваций и на них перестает работать вбитое в детстве «надо». Потому что, кому надо? Зачем надо? Ведь если проект не делается, то среди прочих причин есть и очевидная — разработчику проект не нужен и не интересен, все самое «вкусное» уже решено, а оставшийся внутренний профит от нудного доведения проекта до ума или мал, или вовсе отсутствует. Дальше начинается бессмысленная борьба с собой, которая при любом исходе ведет к депрессии. Даже если «надо» победит и разработчик, сжав зубы в кулак, сделает то, что собирался, то в конце работы он получит не счастье, а ощущение типа «отмучился наконец-то...», с растущей неприязнью к последующим проектам. Если же он будет так делать систематически, то закончится это неврозами, нервными срывами, депрессиями, а то и посещением психиатра (да, уже не психолога).
Что же до позитивной мотивации, то мне, к примеру, интересно работать в группе. Когда есть вызов, когда скорость изменений в проекте выше чуть ли не на порядок, когда можно наиболее неприятную часть отдать кому-то, кого она не напрягает (или не так напрягает). Так я могу работать годами без всяких депрессий и прокрастинаций. А вот в одиночку так не выходит — скучно… даже радостью от красивого решения поделиться не с кем.
Гхм, выглядит интересно, но что случилось со старой доброй пошаговой эмуляцией смешанной с методом Монте-Карло? В смысле, что проводим (условно) N раундов-обменов уроном, смотрим сколько и кого осталось, записываем, кто победил и повторяем это еще 100,000 раз, чтобы после построить график.
Это позволяет, среди прочего, работать со сложно формализуемыми параметрами. Вон у вас какие зубодробительные формулы получились на всего лишь несколько видов вооружения. А если туда добавить хотя бы классическую схему, где стрелки стреляют по всем, а солдаты ближнего боя могут атаковать только солдат ближнего боя и лишь если их нет — стрелков? А если нужно протестировать влияние героя, который сам наносит какой-то урон, дает бонусы армии или осуществляет стратегическое управление, например, переводит бойцов ближнего боя в режим защиты, если есть превосходство в стрелках или фокусирует стрелков на наиболее опасных вражеских юнитах? А если есть лечение и вампиризм, т.е. лечение уроном, саммон (включая временный), сопровождающие заклинания, влияние местности (на тех же стрелков), сверхмощные одиночные юниты, из-за которых бой буквально делится на «до» и «после» их гибели и т.д. — что тогда?
Это предельная частота для Arduino, вроде как. Ниже можно, а выше — уже сложнее.
Ну и, насколько я помню, значительная часть полевых транзисторов работает на частотах до 100кГц. Если выше, то там возникают нехорошие эффекты типа недопереключения.
дорогих и громоздкихкомплексных решений не видите очевидных плюсов такой интеграции.Если вы знаете какие-то хорошие магазины, которые можете порекомендовать — напишите, пожалуйста, список. Я посмотрю и добавлю апдейтом.
Чтобы не доводить дело до перепрошивки, можно делать это не сразу, а по команде с сервера. Или через выполнение другого файла с задержкой в секунду (успеете стереть). В моем случае ESP при включении качает с сервера файл с lua и запускает его, что позволяет, к примеру, одним копированием перевести его в telnet-сервер, чтобы посмотреть что там и как.
Само общение идет как-то так:
"\n" означает, что функция будет вызвана как только встретится символ "\n", можно вместо этого указать, например, минимальное количество.
Arduino выступает в роли исполнительного модуля. На него цепляется самое разное железо. Например, если нужно считать показания с трех датчиков (температура-влажность, давление, уровень CO2) и вывести результаты на двухстрочный LCD-экран, то как сделать это одним ESP?
Насчет DNS.
18:36:55.097770 IP 192.168.10.36.4096 > 192.168.10.1.53: 0+ A? esp. (21)
18:36:55.097855 IP 192.168.10.1.53 > 192.168.10.36.4096: 0* 1/0/0 A 192.168.10.1 (37)
18:36:55.097862 IP 192.168.10.1.53 > 192.168.10.36.4096: 0* 1/0/0 A 192.168.10.1 (37)
18:41:56.111751 IP 192.168.10.36.4096 > 192.168.10.1.53: 1+ A? api.pushingbox.com. (36)
18:41:56.111751 IP 192.168.10.36.4096 > 192.168.10.1.53: 1+ A? api.pushingbox.com. (36)
18:41:56.111845 IP 192.168.10.1.53 > 192.168.10.36.4096: 1 1/0/0 A 213.186.33.19 (52)
18:41:56.111853 IP 192.168.10.1.53 > 192.168.10.36.4096: 1 1/0/0 A 213.186.33.19 (52)
Оба запроса пришли на мой DNS-сервер (192.168.10.1) и он же ответил на них.
Интересно, почему отправляется сразу по два запроса?
Единственный непонятный мне запрос, это вот этот:
18:36:54.966762 IP 192.168.10.36 > 224.0.0.1: igmp v2 report 224.0.0.1
Почему же они затратные? Одна симуляция считается сотые доли секунды. И множество симуляций нужно только если есть разброс параметров из-за рандома, в т.ч. ведущего к ветвлению, который ваша система вообще не может учитывать.
Без проблем, но баш на баш — представьте сначала, скажем, итоговую систему уравнений для размена при котором каждый отряд имеет всего пять параметров: очки здоровья (на юнит), урон (на юнит), броня отряда (вычитается из всего входящего урона за раунд), шанс крита (шанс нанести двойной урон в раунд, применяется до брони). Да, кстати, не забудьте обосновать, что непрерывные функции подходят для вычисления заведомо дискретных разменов.
Почему вы считаете, что это затратно?
А я это уже сделал, когда захотел проверить выводы насчет потерь.
use strict; for (my $pp = 0; $pp < 100000; $pp+=100) { my $L1 = 100000; my $L2 = $pp; my $k = 0.01; while ($L1 > 0 && $L2 > 0) { my $LN1 = $L1 - $L2 * $k; my $LN2 = $L2 - $L1 * $k; $L1 = int($LN1); $L2 = int($LN2); } print "$pp $L1\n"; }А вот так выглядит график построенный по выводимым данным:
Обратите внимание на характерную точку 80,60 (0.8, 0.6 в вашем случае).
Ну и, чтобы дважды не вставать, про время:
$ time perl a.pl > data
real 0m0.033s
А это один поток на половине ядра шестиядерного процессора 2011г., работающего на пониженной частоте. И язык — интерпретатор.
Выше я предложил пример для решения. Всего пять параметров. Мне нетрудно добавить их в симуляцию и построить графики, включая трехмерные, по любым соотношениям любых параметров.
Вообще-то нет. Я утверждаю, что ни к чему учиться брать интегралы в конкретном случае, типа работы портного, который может просто взять сантиметр и измерить весьма сложную и нелинейную фигуру клиента. В задачах, где вычисление одной точки без оптимизации занимает дни, а порой месяцы — безусловно нужна аналитика. Но геймдизайн к таким не относится.
Мы изначально рассматриваем строго определенный отрезок, а именно — потери отряда. Они определены от нуля до 100 процентов. Ниже нуля они быть не могут, выше 100% — тоже. Так какое мне дело до вида функции вне рассматриваемых рамок?
Так же, как и оценка по среднему, только берется сумма оценок взаимодействия каждого отряда с каждым.
А с чего вы взяли, что это возможно? Ваш пример с термодинамикой забавен. Ну да, в идеальном цилиндре, с идеально измеряемыми параметрами системы все просто и модель более-менее соответствует реальности. А теперь представьте, что у вас не цилиндр, а штук сто сообщающихся сосудов, с разной теплопроводностью, часть из которых при разной температуре становится упругой и может менять объем, а часть оборудована автоматическими клапанами, срабатывающими при определенных условиях, некоторые их них даже стравливают часть газа наружу, а в некоторых газ дополнительно охлаждается до состояния жидкости или подогревается до состояния плазмы. Как вы, вооруженные самым передовым знанием, что pV=NRT, сможете определить параметры системы на выходе? При этом сделать тысячу замеров результата работы этой системы сможет даже лаборант.
Вы решили задачу об обмене уроном между всего лишь двумя отрядами без каких-либо особенностей. Для ГД это что-то уровня «Hello world!», а «полноценная симуляция» в рамках решенной вами «задачи», это пять минут работы программиста-новичка. Только вот если потребуется добавить особенностей — это будут все те же пять минут, а у вас сложность резко нарастает. Кроме того, в самой игре обмен будет идти точно так же, как в симуляции, собственно, обычно симуляция и делается с использованием модуля для боевки. Это гарантирует отсутствие ошибок, включая накапливающиеся ошибки из-за отсутствия дискретности у вашей модели. Ну, а про использование любимого метода всех ГД — разброса параметров с помощью всемогущего рандома — даже как-то уже упоминать неудобно.
Полагаю, что предлагаемый вами метод полезен общего развития, чтобы ГД примерно представляли как проходят размены в простейших случаях. Но никакого практического смысла он не имеет.
Если есть такие опасения, то можно по графику воссоздать функцию.
Это легко автоматизируемый процесс. К примеру, редактор после изменения изменении параметров может проводить симуляции и составлять таблицу значений. После чего изменять, а в том числе и добавлять различные особенности и новые виды войск сможет кто угодно. А в вашем случае геймдизайнер обречен на постоянную борьбу с системой уравнений.
Да, но по принципу «сферического коня в вакууме» — т.е. ничего конкретно применимого. Ну нет игровых систем, основанных только на простейшем размене с плавным падением численности. Везде транзакции, рандом, кучи коэффициентов, мер и контрмер. Иначе, какой интерес?
Работа модификаторов может зависеть от численности нелинейно. К примеру, отряд может иметь дополнительно шанс критического урона, зависящий прямо (или обратно, берсерки, например) от соотношения оставшейся численности отряда к максимальному значению. В случае очень больших значений размена (кстати, в играх обычно соотношение атаки к защите что-то типа 10-25%, т.е. все заканчивается куда быстрее) начинает играть роль неодновременность транзакций (бонус первого удара за засаду на местности, позволяющей делать засады). Или отряд может некоторое время поглощать урон не теряя численности (разнообразные виды защиты).
Я всячески желаю удачи, поскольку если вы сможете довести идею до уровня конечного приложения, способного к анализу по указанным параметрам — это будет чудесно. Но при этом я полагаю, что вряд ли хотя бы один геймдизайнер из тысячи будет сам составлять и решать систему уравнений, хотя бы в силу того, что большинство из них испытывают головную боль даже от элементарных операций с вероятностями.
Так для этого же и существуют графики, разве нет? Кроме того, все-таки обычно геймдизайнеры создают свою систему, а не изучают какую-то чужую и примерно представляют как именно она себя ведет.
А боту будет достаточно и десятка симуляций, чтобы более-менее достоверно предсказать результат поединка. Но есть способы предварительно упростить вычисления. Например, заранее составляется таблица соотношений размена юнитов в боях друг с другом. Условно, сколько нужно юнитов А, чтобы уничтожить тысячу юнитов Б. Затем по ней быстро оценивается взаимная сила армий. В особо примитивных случаях все вообще сводится к вычислению условной средней силы каждого юнита и сравнению суммы этих параметров, если расхождение в нужных рамках — тогда уже симуляция.
Боюсь, вы мало имели дела со стратегическими играми, если представляете себе сведение всех условий (тип местности, броня, выучка и т.д.) к одному линейному коэффициенту k. Он в лучшем случае — степенной. Кроме того, зачастую юниты в стратегических играх обладают лимитированным количеством дополнительных возможностей — способностями к разовому исцелению раненых (вариант: вызов подкрепления), к нанесению резкого (burst) урона с последующим бездействием или без такового, к временному контролю отрядов противника (suppression, cc) и так далее. Именно эти способности требуют наибольшего внимания от ГД, поскольку именно в них таятся опасности критического дисбаланса — как вы все это будете учитывать?
Можно взять более поздние игры, там добавляется еще и позиционирование, понятия «подавления» и «навязывания» боя, «прикрытие» (дополнительная атака стрелков прикрывающих указанный отряд), дальность атаки и многое другое.
Мне кажется, что вашу схему можно использовать только если специально под нее создавать дизайн боевки, ограничивая все нелинейности и отрезая все возможные ветвления.
А после тридцати я вообще перешел на альтернативный транспорт (ролики и самокат в теплое время года, пешком — зимой) — около 14 км. каждый день, это с одной стороны решило проблему с необходимыми физ. нагрузками при сидячем образе жизни, а с другой оказалось удобным способом приводить мысли в порядок до и после рабочего дня.
Конечно есть люди, которым нравится водить автомобиль, в смысле — нравится сам процесс, но, как мне кажется, их очень немного.
Насчет квартиры и прочего — есть у меня знакомая, которой нравится улучшать жилищные условия и покупать новые машины раз в 3-4 года. Она еще до обвала доллара смогла добраться до ежемесячного дохода в 200к рублей (на те времена около $7к). Увы, нервозность, депрессии, склонность к истерикам и все прочие признаки нервного истощения и переутомления были ее постоянными спутниками. Я уважаю ее выбор, но сам так жить не хочу и не буду.
1. Большая з/п. Новичковая мотивация. Через некоторое время оказалось, что тратить деньги банально не на что — мне не интересны машины, яхты и золотые унитазы. Мне не нужна эксклюзивная и дорогая еда, в том числе и по врачебным рекомендациям. Мое хобби стоит недорого. Я с легкостью укладываюсь в 500$ в месяц, при том, что с легкость могу претендовать за з/п от 2500$, а если подпишусь на руководящую должность, то и от $4k. В итоге, за год я обеспечу себя еще на годы вперед. Когда денег скопилось какое-то неприличное количество, я традиционно вложился в недвижимость и теперь, как представитель мелкой буржуазии могу вообще не работать до конца жизни. Так на кой мне повышение зарплаты, если избавиться от установки «надо зарабатывать больше, потому что это — показатель успеха»?
2. Больше времени. Есть такая шутка, что одна сигарета сокращает жизнь на пять минут, а рабочий день — на 8 часов.
3. Более интересные задачи — это нонсенс. Чем выше профессиональный уровень, тем меньше остается интересных задач в своей области, потому что все вокруг превращается в боян и примитив. Один из вариантов выхода написали в соседней ветке комментариев — регулярная смена области профессиональной деятельности. У меня есть коллега, который раз в два года меняет язык разработки, а раз в шесть-восемь лет — область. У меня есть другой коллега, который радостно хватается за любой новый фреймворк или язык — сейчас вот он фанатеет по Свифту, например. Оба они оптимистичны, бодры и им нравится жизнь.
Что же до позитивной мотивации, то мне, к примеру, интересно работать в группе. Когда есть вызов, когда скорость изменений в проекте выше чуть ли не на порядок, когда можно наиболее неприятную часть отдать кому-то, кого она не напрягает (или не так напрягает). Так я могу работать годами без всяких депрессий и прокрастинаций. А вот в одиночку так не выходит — скучно… даже радостью от красивого решения поделиться не с кем.
Это позволяет, среди прочего, работать со сложно формализуемыми параметрами. Вон у вас какие зубодробительные формулы получились на всего лишь несколько видов вооружения. А если туда добавить хотя бы классическую схему, где стрелки стреляют по всем, а солдаты ближнего боя могут атаковать только солдат ближнего боя и лишь если их нет — стрелков? А если нужно протестировать влияние героя, который сам наносит какой-то урон, дает бонусы армии или осуществляет стратегическое управление, например, переводит бойцов ближнего боя в режим защиты, если есть превосходство в стрелках или фокусирует стрелков на наиболее опасных вражеских юнитах? А если есть лечение и вампиризм, т.е. лечение уроном, саммон (включая временный), сопровождающие заклинания, влияние местности (на тех же стрелков), сверхмощные одиночные юниты, из-за которых бой буквально делится на «до» и «после» их гибели и т.д. — что тогда?
Ну и, насколько я помню, значительная часть полевых транзисторов работает на частотах до 100кГц. Если выше, то там возникают нехорошие эффекты типа недопереключения.