Определился. Будет две "пользовательские" библиотеки, в кавычках, потому что я пока еще не решил, буду ли раскрывать их сорцы всем желающим.
Progs.dll и GameUI.dll. В первой будут находится все энтити единый клиент-серверный массив, он же используется для рендеринга и в самих энтитях будет метод Draw ну или что-то вроде этого. И GameUI.dll где клиентский худ и главное меню. Их нет смысла разделять, это по сути один хрен.
а в ядре остаётся абстрактный бакэнд, работа с файловой, сетью, форматами моделей и звуков.
Дядя Миша писал: В первой будут находится все энтити единый клиент-серверный массив, он же используется для рендеринга и в самих энтитях будет метод Draw ну или что-то вроде этого
Вот этот подход, он очень развращает. Человек перестаёт мыслить клиент-серверно, постепенно деградирует, в его модах половина эффектов начинает работать исключительно у локального игрока, а заканчивается всё поиском класса камеры в чужих сорцах.
VM попозжы. Но скорее всего она будет. Потому что очень многие вещи энтитями делать невдобно, хотя и реально. Это какой-то артхаус получается, вот мне правильно Ксер подсказал.
У нас мульти_ватчер это кондиция, а мульти_свитчер это свитч-кейсы. И вот мы на этом пытаемся собрать логический код. Там где хватило бы нескольких строчек в скрипте.
Цитата:
XaeroX писал: Человек перестаёт мыслить клиент-серверно, постепенно деградирует
У нас клиент-серверно даже Мастер мыслить не мог, всё удивлялся, почему он на сервере квары настроит, а нелокальный игрок их невидит.
Надо наоборот, чтобы это было прозрачно для пользователя. Чтобы он не гадал почему у него что-то не передалось, а он забыл в дельте строчку прописать. Меня самого это всегда бесило. Там скопируй, тут скопируй, в дельте пропиши, найди свободную переменную, да идите вы нафиг с такими приколами. Почему юзер должен таким бакэндом заниматься?
В сорсе не лучше, там еще хуже. Сперва объяви перемменную как CNetworkVar, потом из этих переменных создай табличку отправки на клиент, потом на клиенте построй точно такую же таблику, потом вручную прими все переменные, проинтерполируй по вкусу. На кого это рассчитано?
XaeroX писал:
Человек перестаёт мыслить клиент-серверно, постепенно деградирует, в его модах половина эффектов начинает работать исключительно у локального игрока
Разве при аццуцтвии клиент-серверного разделения оно не будет работать у всех одинаково?
nemyax
Оно будет работать там, где оно имеется. Создали объект на сервере - имеем его на сервере. Создали на клиенте - имеем его на клиенте. А для синхронизации уже нужны приседания. Дядя Миша, видимо, хочет эти приседания заранее предусмотреть и всё-всё синхронизировать автоматически, при этом максимально экономя трафик. Пока звучит как утопия. Но будем посмотреть.
Насчёт экономии трафика я ничего не говорил. Я исхожу из того очевидного, но упорно игнорируемого соображения, что ситуации, в которой нам может понадобиться два комплекта энтить попросту не существует. Если сервер в режиме дедика - это один комплект энтить. Если клиент подключился к удалённому серверу - это один комплект энтить.
Таким образом для любого сетевого подключения нам требуется один комплект энтить. Чтобы это понять необязательно даже глубоко разбираться в теме. И два комплекта нам почему-то требуются в случае локальной игры, т.е. там где они точно так же не нужны. А поскольку локальная игра, это еще и синглплеер, мы имеем бесполезный перерасход памяти на два набора энтить. Какой в этом смысл? Да никакого абсолютно.
Это такая же пакость, навроде SQB, однажды сделали неоптимально и потом тащили аж до третьей кваки. Но там еще дальше пошли - там и карту зачем-то два раза начали загружать, отдельно для коллизии и для рендеринга. Опять таки смысла никакого.
Я вам так скажу это основная беда движкописателей - взять какой-то форк за основу и на этой основе просто наворачивать тени мягкие, физику и так далее. Осознать, что архитектура требует пересмотра никто не может и не хочет. Даже Ксерокс.
Добавлено 08-09-2019 в 16:09:
ЗЫ. конечно если в игре предполагается 600-900 эдиктов, то как бы и пофигу. А вот 20-30 тысяч уже не получится при таком раскладе.
И вот мы на этом пытаемся собрать логический код. Там где хватило бы нескольких строчек в скрипте.
Именно так и получается. Причём если делать в джеке, то из этих связок энтить получается write only каша, на которую если через неделю взглянешь, то вспомнить что там куда и кого активирует становится решительно невозможно. Я из-за этого всё это в отдельные .ent-файлы оформлял, но и там опять же то что на DSLе выразилось бы в пару строчек разрастается на пару десятков. А казалось бы, столько возни ради простой конструкции вроде префаба лифта с защитой от дурака. А с поездами ещё замороченней, особенно если их несколько на линии.
Да надо просто как в том же Doom3 сделать глобальные скрипты, локальные скрипты, ну что-то вроде этого. Ну то потом всё, это архитектуру не затрагивает никоим образом, скорее приятное дополнение.