Как вы разрешаете писать сетевой код на более поздних этапах разработки?

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

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

Изменить: планируется быть сверху вниз RPG. Я думаю о простом мультиплеере, где вы размещаете сервер для своих друзей, поэтому обман не так уж и важен (кто хотел бы поиграть с обманщиками?). Тем не менее, я хотел бы пойти с подходом «сервер всегда прав».

Редактировать 2: Я думаю, что я ищу некоторые указатели на то, каким должно быть мое мышление. Как я должен обрабатывать ввод с клавиатуры, анимацию и т. Д. Вместо того, чтобы просто применять каждый эффект / изменение мгновенно. Хммм, мне, возможно, придется внимательно прочитать информацию о сети, прежде чем идти куда-либо, от чего я надеялся избежать создания сетевого скелета, который мог бы работать локально.

Не зная больше о конкретной игре, которую вы пишете, и о том, как вы ее пишете, очень сложно найти общие решения вашей проблемы.

Тем не менее, вы можете подумать о том, что вы решите оставить сетевой код до конца, в зависимости от того, насколько важным является сетевое взаимодействие для вашей игры.

Я имею в виду, что если вы пишете тяжелую сетевую игру, такую ​​как MMORPG, возможно, не стоит оставлять сеть до конца.

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

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

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

Таким образом, создавая свою игру, вы будете знать, на какие части влияет сетевой код, и когда придет время написать сетевой код, вы на несколько шагов впереди.

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

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

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

Мой подход совпадает с вашим комментарием к IPC (межпроцессное взаимодействие).

Сначала я изучаю книгу Стида и Оливейры «Сетевая графика». Это обеспечивает хорошее представление о различных сетевых архитектурах для игр в зависимости от различных критериев и типов игр. Он предоставляет инструмент, который поможет вам определить архитектуру вашей игры и то, что именно вы хотите разместить в сети, и что вы хотите, чтобы происходило локально.

Во-вторых, разделите сетевые компоненты в отдельный фоновый поток, чтобы в вашей первоначальной разработке игры компонент был закодирован локально, но вы вынуждены иметь дело с разделением потоков. Не объединяйте их с какими-либо другими функциями, которые впоследствии станут «локальным фоном», но форсируйте их в «потенциально удаленные» фоновые потоки.

Это должно помочь отделить вашу логику, а также позволит вам симулировать сетевые факторы задержки в процессе, чтобы вы также могли видеть влияние задержки.

Если вы узнаете обо всем этом, почему бы не написать простую однопользовательскую версию 1, и, как только она заработает, со своими более глубокими знаниями переосмыслите все это для версии 2, которая будет многопользовательской?

Реализуйте класс «поддельной сети», который передает сообщения между потоками, который имеет тот же интерфейс, что и сетевой класс. Позже вы можете разработать поддельную сеть для случайных задержек и потери пакетов. Отладка сетевого кода с помощью фальшивого класса всегда будет проще, чем в реальной сети.