xmoonlight

1. Создайте общее "дерево" зависимостей сущностей (work-flow).
2. Создайте роли для разных объектов (пользователей/групп/сервисов и т.д.).
3. Создайте битовые ACL-"маски" для конкретных объектов и привяжите их к нужным узлам "дерева".
4. Если нужно управлять доступами динамически: создайте доп."маски" доступов (service override ACL) и меняйте их конкретным сервисом.

Edraw Max
Пример (взято отсюда):

Такой вид товарного предложения называется "вариативное товарное предложение".

1. Создаётся унифицированный товар, как дополнительный подраздел в нужной категории товаров и, желательно, помечается флагом "унифицированный товар".
2. Создаются все доступные к приобретению варианты сочетаний, как отдельные товарные предложения.
3. В скобках наименования указываем все параметры попарно через двоеточие с разделением точки с запятой.
Пример: Портативный SSD (объем:128Gb;цвет:красный)
4. Затем, в эту категорию помещаются все созданные сочетания товарных предложений.
5. При отображении товара из категории "унифицированный товар" (или, если есть в наименовании товара двоеточие в скобках) - определяем, что товар - вариативный.
6. Если это так - делаем выборку, предварительно исключив скобки (или проще: все товары этой категории) из БД.
7. Если таких товаров несколько - отображаем варианты для выбора.
8. При изменении одного из вариативных параметров пользователем - меняем товар через ajax (или полностью перегружаем страницу, что хуже...)

Еще раз, повторюсь: если пометить категорию в п.1 не представляется возможным, можно просто ориентироваться на скобки и двоеточие, и создавать селекторы по этим признакам.

----------

Если делаете с нуля, всё просто:
1. Добавляете к разделу флаговое поле в БД: "вариативный товар"
2. Добавляете отдельную таблицу вариативных характеристик, в которой присутствуют связки:
ID раздела "вариативный товар", ID одной характеристики товара, тип поля (лучше ID поля и доп.таблицу, канешн, но не так критично, если вариантов не много)
3. Если товаров из нужного вариативного раздела с такими характеристиками у нас несколько - отображаем выбор параметров.
4. см. п.8 (из предыдущего раздела)

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

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

Как я понял: речь про баланс: контроль игрового мира <-> объём передаваемых данных по сети.
Вопрос хороший.
Не всегда нужно делать всё на сервере, иначе объём трафика - возрастёт дико во время игры. Но также, нельзя доверять клиентским данным.
Поэтому, всегда делается аппроксимация: промежуточная визуализация - вычисляется на клиенте, а пришедшие на сервер данные - всегда тщательно проверяются сервером в рамках логики(модели) работы игрового мира. И если отклонения слишком велики - фиксируется "читерство", иначе - по получению новых позиций объектов, клиент плавно, но с ускорением ("параболически") устраняет расхождения с серверным игровым миром: синхронизирует актуальное состояние мира сервера с отображаемым пользователю.
Это происходит в 99% случаев незаметно для глаз игрока за монитором.

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

Если Вы думаете, что всё там в Real-Time - это заблуждение.
Командами с клиента - Вы лишь отдаёте изменение состояний серверу.
А время - оно одинаково течёт и на сервере и на клиенте.
Поэтому просто стоит привязка к таймеру и синхронизация времени и получение/обновление новых событий время от времени.

Всё развитие - это изменение значений во времени по определённым правилам, что автоматически означает, что это не online-шуттер или аркада, где от постоянного изменения координат зависит состояния других объектов за короткий промежуток времени.
Такое - потянет даже самый слабый хостинг, т.к. это просто POST-запросы к серверному API для обмена данными в формате json (например).

Серверное API проще всего сделать на простом PHP.
Конечно, можно сделать и на WebSocket, но для такого типа игр - это overwork.

я останавливаюсь на простой ошибке и сижу над ней полдня, как это исправить?

Варианта 3:
1. Вы не понимаете английский язык
2. Вы не понимаете терминов, выводящихся в ошибке из-за слабых знаний языка.
3. Вы не понимаете логики работы своего же кода.
Нужно устранять эти "пробелы" через понимание и запоминание.

Вот памятка о том, как лучше делать, чтобы не путаться.