Какой подход выбрать? Плюсы и минусы?
1. Разбить код (модули, системы) на инклюды и подключить в один главный файл для управления всем
2. Каждую систему/модуль писать как отдельный плагин и взаимодействовать через api
как Shop, например: сам Shop является ядром, а все остальные плагины завязаны уже на него через создаваемые им нативы и форварды
Сообщения автоматически склеены:
@gnull, это просто монолитный плагин. А разбивка просто для удобства, чтобы не искать нужную часть кода по всему исходнику. Но это создаёт дополнительные проблемы при компиляции (видимость функций и переменных нужно учитывать) и редактировании, если пишешь код в блокноте (который даже не ++), как я.
как Shop, например: сам Shop является ядром, а все остальные плагины завязаны уже на него через создаваемые им нативы и форварды
Сообщения автоматически склеены:
@gnull, это просто монолитный плагин. А разбивка просто для удобства, чтобы не искать нужную часть кода по всему исходнику. Но это создаёт дополнительные проблемы при компиляции (видимость функций и переменных нужно учитывать) и редактировании, если пишешь код в блокноте (который даже не ++), как я.
Ну для такого понятное дело нужен API, который будет служить связующим мостом между ими, без API, дополнительные .sp не будут понимать что ты от их хочешь
не согласен. Если sp подключать в main.sp, то без api реализуется все. Пример кода main.sp
C-подобный:
#pragma semicolon 1
#include <sourcemod>
#include <sdktools>
#include <sdkhooks>
#include "mymode/sys/datasystem.sp" // Системные данные
// === Данные игрока === //
#include "mymode/dataplayer/data_main.sp" // Основные данные игрока
#include "mymode/dataplayer/data_temp.sp" // Временные данные игрока
#include "mymode/dataplayer/data_stat.sp" // Статистика игрока
Для удобства конечно нужно делить плагин, но не заниматься тем, что для каждой мелкой функции отдельный файл, ну и плагин с отдельными функциями(которые используются разово) будет работать медленнее, нежели в 1 фунции
Рекомендация: Гибридный подход (Domain-Driven Design)
Однозначного победителя в этом споре нет. Выбор между монолитом и микросервисами (в контексте плагинов) — это классический компромисс между простотой и надежностью/масштабируемостью.
На основе предоставленных плюсов и минусов, наиболее рациональным решением выглядит не выбор одного из двух путей, а использование гибридной стратифицированной архитектуры на ранних этапах:
Ядро (Core) как «Главный плагин»:
Создайте один основной плагин, который будет отвечать только за фундаментальные вещи: общие структуры данных, критически важные утилиты и управление состояниями. Это та часть, где прямой доступ к памяти оправдан скоростью и стабильностью.
Модули как «Сервисы» с API:
Каждую логическую фичу (экономика, инвентарь, квесты) выносите в отдельные плагины.
Они не имеют прямого доступа к данным ядра. Вместо этого Ядро предоставляет четкий API (набор нативных функций и форвардов). Модули общаются только через этот API.
Почему это оптимально:
Компромисс по скорости разработки: Вы получаете быстрый старт, прописывая логику в главном плагине, но сразу выделяя слой API, чтобы позже не переписывать всё с нуля.
Устойчивость: Если упадет плагин-модуль (инвентаря), ядро и другие модули продолжат работу. API-слой выступает буфером и точкой стабилизации.
Масштабирование команды: Один разработчик может фиксить ядро, другие — писать модули, не боясь сломать общую логику, так как они взаимодействуют только через контракты (API).
Итоговый вердикт:
Если ваш проект — это прототип или маленький сервер для друзей, выбирайте Вариант 1. Это быстрее и проще.
Если ваш проект рассчитан на долгую работу, рост и команду разработчиков, выбирайте гибридную модель на пути к Варианту 2. Четкие API и разделение ответственности окупят затраты на проектирование в будущем.
Представляем Ядро Системы Воскрешений — уникальный плагин, который даёт возможность возрождения павших союзников на сервере! Система поддерживает два типа воскрешений: обычные и привилегированные, с настраиваемым временем оживления для каждого типа. Привилегированные игроки могут воскресить союзника за 1 секунду, тогда как обычным игрокам требуется 6 секунд. Вы также можете задать радиус воскрешения и выбрать место появления воскрешённого: на месте его смерти или рядом с воскрешающим игроком.
Каждый раунд система автоматически выдаёт указанное количество попыток воскрешения как обычным, так и привилегированным игрокам. Воскрешение можно активировать через кнопку «E» или просто, находясь в пределах радиуса действия у тела союзника.
Расширить функционал можно с помощью модулей:
[Res] Add — добавляет дополнительные очки воскрешений для всех игроков в конце раунда.
[Res] 1 vs 1 MyArena — отключает возможность воскрешения в битвах 1 на 1 (плагин WeaponFight MyArena).
[Res] Bonus kills — за каждые два убийства игрок получает одно дополнительное воскрешение.
[Res] Info — текстовые уведомления о начале и завершении процесса воскрешения.
[Res] Restriction — блокирует воскрешение игроков, убитых в голову или ножом.
[Res] Round END Time — ускоряет воскрешение обычных игроков до 1 секунды в конце раунда.
[Res] Set frags — за каждое успешное воскрешение игрок получает дополнительные фраги.
[Res] Set health — настраивает уровень здоровья воскресившего и воскрешённого игроков.
[Res] Spec — предотвращает воскрешение игрока, который переходил в режим наблюдателя и обратно.
[Res] Status info — отображает количество воскрешений в HUD, с настройками цвета и положения.
[Res] Visual effect — создаёт эффект извивающейся электрической спирали в зоне воскрешения.
[Res] Visual support — добавляет логотип павшего союзника, который видят только игроки с попытками воскрешения.
[Res] Visual support v2 — расширяет предыдущий модуль возможностью настройки высоты и цвета значков.
это типо такая модульная система?)
сделано конечно круто, но вопрос где это удобно?
только для продажи? а если это заранее был бы опенсорс, то не проще все в один модуль пихнуть раз тут плагин по теме воскрешения?
вот даже с точки зрения этого примера, на каждый пук свое "расширение" модуля.
Это не медлит алгоритм в целом, если бы это было в одном месте? или зависит от архитектуры модуля? тоесть если скажем расщирения не используют калбеки SM а только форварды ядра, то по сути пофиг на количесвто этих расширений?
я к тому, что если не использовать в каждом модуле отдельные OnMapStart() итд, а подхватывать их уже из ядра
с другой стороны хуки эвентов, в каждом модулей скорее всего придется использовать отдельный хук?
выходит множесвто вызовов?
@goldfish, модульная структура нужна, если требуется возможность менять доступные возможности плагина не перекомпилируя его. За основное отвечает ядро, а за дополнительные возможности, изменения поведения и/или подключение к другим ядрам уже отвечают модули.
Сильно зависит от того что требуется сделать модулем.
Ядро может не отлавливать вообще никаких событий, не использовать OnMapStart(). Зависит от того что от ядра требуется и как его решил написать автор.
Может создавать свои события (форварды).
(теория мертвого интернета)
