правильное моделирование обработки сообщений/дискретных событий

разбить каждую операцию на два шага

всё это происходит в один и тот же момент времени

Особо никто этим не заморачивается. Т.к. в настоящем мире все точно так же: либо успел, либо нет.

Введи понятие ограничения скорости действия. Т.е. удар магией происходит за 0.25 сек., а лечение за 0.30 сек. Тогда случай «одновременно» это нонсенс. Игрок должен кликать быстрее или в чем смысл твоего одновременно, если железо накладывает ограничения (сеть: 10мс+, экран 60фпс, а глаз 24 кадра/сек.)?

ИМХО. Не спец.

Ну, и быть предвзятым судьей это как-то уж совсем нечестно. Предположим что у тебя есть положительное действие (усилить защиту) и противодействие (понизить защиту). «Все это происходит одновременно». Встав на чью-то сторону будет ли вариативность? Нет, видно, что писал код пацифист, поэтому усиление защиты всегда будет перекрывать ее понижение. Думай как «размазать» такие случаи так, чтобы они были рандомными, а не так, чтобы было ясно, что произойдет. Я такое делал не для игры, были весьма сильные округления времени и «размазывал», хотя полученную последовательность соблюдал в том порядке, в котором расчеты уже надо было производить.

Тогда случай «одновременно» это нонсенс

Это почему же? если у нас совпадают окончания обоих процессов это и будет «одновременно».

а знает ли кто-нибудь что-то интересное почитать по таким вопросам.

Я дилетант, вообще-то, но, мне кажется, эта тема непосредственно пересекается с моделью акторов. Там есть понятие «арбитр», который «умеет» делать недетерменистский выбор. На вход арбитра поступают одновременно 2 сигнала, но выходит одномоментно только один. Насколько мне известно, модель Акторов — это единственная модель вычислений, где такое возможно. Это называется неограниченный индетерменизм.

«Заключение эксперта» о смерти юнитов нужно делать после проведения всей бухгалтерии по каждому из них. А то у тебя транзакция «подсчет/смерть» проводится по единственной операции, которая первой достигнет нуля ХП.

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

не густо(((

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

u2.cast_magic_to(u1); // 100-100=0, died.
u3.cure(u1); // 0+50=0, already died.
//---
u3.cure(u1); // 100+50=100, ignore.
u2.cast_magic_to(u1); // 100-100=0, died.

Следовательно, вам нужно уметь разбираться с теми воздействиями, которые накладываются на unit-ы. Т.е. u2 не непосредственно влияет на u1, а лишь передает воздействие «cast_magic». Аналогично, u3 передает воздействие «cure». Первый юнит не сразу применяет к себе полученные воздействия, а с каким-то временным лагом. Например, раз в 100ms юнит суммирует все оказанные на него воздействия и применяет результат к себе.

Реализовать это можно, как минимум, двумя способами.

1. Простейшая потактовая работа. Т.е. раз в Nms каждый unit «просыпается» и выполняет какие-то действия. Например, если у него есть необработанные воздействия, полученные во время «сна», он суммирует их, применяет результат к себе и вычисляет свое новое состояние («жив» или «убит»). Если оказывается жив, то инициирует действия согласно своей логики (посылает на кого-то магию, лечит кого-то и т.д.). После чего опять «засыпает» на Nms. Все воздействия, которые приходят к unit-у в течении «сна» не обрабатываются сразу же, а складываются в очереть, с которой unit разберется на следующем такте.

2. Unit получает воздействие, но не обрабатывает его сразу, а кладет в очередь. После чего сразу же взводит таймер на Kms. Тем самым образуется некий лаг во времени, в течении которого unit позволяет прийти дополнительным воздействиям. Если они поступают, то unit просто добавляет их в свою очередь. Когда через Kms приходит сигнал об истечении таймера, то unit суммирует все воздействия из очереди и применяет результат к себе. Тут все не сложно, нужно только следить, чтобы таймер взводился только когда первое воздействие помещается в пустую очередь. Если же очередь не пуста, то таймер взводить не нужно.

Правильно ли я понял условия задачи? Или вам требовалось что-то другое?

Правильно ли я понял условия задачи? Или вам требовалось что-то другое?

да вроде нормально. Пойду поизучаю systemc, думаю там можно что-то более теоретическое узнать. Kms = 0 добавлять к каждому моменту времени с событиями и организовывать там некую фиксацию, кажется неплохо.

да вроде нормально.

Вы спрашивали, можно ли это смоделировать с помощью SObjectizer. Да, можно. Причем как первый вариант (работа по тактам), так и второй (таймер взводится при получении первого события).

Если интересно, могу попробовать набросать схематичный пример.

Если интересно, могу попробовать набросать схематичный пример.

Нет, спасибо. Не стоит тратить на это время. Подумаю про некий специальный обработчик сообщений(событий).