| мысли и идеи |
Oct. 4th, 2017|03:27 pm |
поскольку сеть у нас в D2D:F сделана, но не лучшим образом (фактически, нахачена сверху; сам по себе хак годный — для условий и сроков, в которые был сделан, но), то сеть тоже надо переделывать, конечно.
я поел, воскурил, и до меня дошло, что не надо пытаться Всё Внутри Переделать. поскольку я хочу, чтобы даже в процессе сильно глубоких изменений у нас всегда была рабочая игра, то долгая кардинальная переделка кишков игры не катит. так вот.
до меня дошло, что и не надо. можно оставить рабочие структуры игры почти что intact, и просто реализовать поверх них нечто вроде proxy entities. таким образом логику игры не придётся шибко перепиливать (разве что подобавлять в некоторых стратегических местах флагов типа «что-то в объекте поменялось», их уже коге-где и так есть). и перевести кусок, который ведает взаимодействием с игроком, с прямой работы с объектами на проксики. таким образом относительно малой болью получается унификация клиентского кода для локальной и сетевой игры. слой же управления собственно логикой остаётся почти без изменений, только уезжает чуть ниже.
то есть, клиентской части становится пофигу, интерполировает ли кто-то внизу данные с сервера, или это local game: он пинает прокси, получает с них данные и все дела.
для рендера будет кодовый путь, который на основе полученых с сервера entities создаёт dummy objects, заполненые по минимуму: лишь бы рендер работал. или не создаёт ничего, если у нас local game.
в игре есть ещё split screen, и он тоже отлично ложится в эту схему. ну, два локальных клиента создадим, делов-то. хоть сорок два.
дельта-снапшоты тоже будут генерироватся из проксиков: они (проксики) спокойно могут хранить прошлое состояние полей, которым нужна синхронизация, внутри себя, и сравнивать с новыми, выплёвывая только изменения. или выплёвывать всё, если это «нулевой пациент». таких полей всё равно немного: в основном координаты и скорость объектов. ну, и animation state для анимированых панелей, потому что оные панели иногда используются в картах для катсцен, например.
код от этого красивей, конечно, не станет, но зато позволит мне делать entity system параллельно с существующей логикой, имея при этом рабочую игру. а когда я более-менее допилю — переключиться на новые механизмы (даже переключаясь на новые куски частично и постепенно, в принципе).
вдобавок, после создания entity system привинтить к ним скрипты будет чуть проще. в принципе, разработку скриптов и entity system тоже можно вести параллельно.
сразу отвечу на незаданые вопросы.
1. код игры сам по себе адский ад. ну, так исторически сложилось: оригинальный автор начинал её делать, будучи ещё нубом. а потом там наслаивалось и наслаивалось. если кто делал проекты, которые живут кучу лет, и начинались как нубокод, а дропать их нельзя — тот может примерно представить, что там внутри.
2. идея «сесть и переписать всё с нуля как надо» была неоднократно. проблемы две. мелкая: надо соблюсти оригинальную физику и квирки 1:1, потому что есть карты, которые заточены под эту механику. и крупная: перепись никогда не завершится. потому что когда есть игра, в которую можно поиграть, то это мотивирует, да и если бросить работу на пол-пути, то у нас всё ещё будет игра, в которую можно поиграть. а если делать с нуля, то игры не будет очень долго, и если бросить перепись, то весь новый код можно смело слить в мусорку, он бесполезен. поэтому переписи не будет никогда, скорее всего. поэтому же игра остаётся на пацкалике.
3. сетки изначально в игре не просто не было: игра даже никогда не задумывалась как сетевая. соответственно, никакого разделения данных на клиент/сервер там нет, все оперируют всем. теперешняя сеть нахачена сверху. мой будущий хак тоже хак, по духу такой же, как тот, что есть, но по сути красивей. |
|