Как эффективно кодировать клиент и сервер одновременно?


15

Я кодирую свою игру, используя модель клиент-сервер. При игре в одиночной игре игра запускается на локальном сервере и взаимодействует с ним, как на удаленном сервере (многопользовательском режиме). Я сделал это, чтобы избежать кодирования отдельного однопользовательского и многопользовательского кода.

Я только начал писать код и столкнулся с серьезной проблемой. В настоящее время я занимаюсь разработкой игры в Eclipse, в которой все классы игры организованы в пакеты. Затем в своем коде сервера я просто использую все классы в клиентских пакетах.

Проблема в том, что в этих клиентских классах есть переменные, специфичные для рендеринга, которые, очевидно, не будут выполняться на сервере.

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


У вас есть опции препроцессора? Например, #ifdef CLIENT <некоторый код> #endif. Это простой способ иметь общие файлы классов, которые могут различаться для сервера и клиента, а также для общих частей. Это немного грязно, хотя.
Уильям Маригер

Я согласен с MindWorX. Хотя условная компиляция является проблемой в Java, есть решения, которые следует рассмотреть.
Сэм Хоцевар

1
Условная компиляция - это грубый способ сказать: «Я не уделил достаточно времени на разработку своих пакетов», по моему мнению =) «Немного грязно» обычно переводится как «Какого черта это делает?» шесть месяцев спустя, когда вы перечитываете даже свой собственный код и неэффективны для всего, кроме одноразовых прототипов.
Патрик Хьюз

Ответы:


23

Вы должны предпочесть хранить код рендеринга отдельно от логики игры , поскольку это отдельная задача .

Если вы отделяете код рендеринга от кода клиента / сервера, вы получаете несколько преимуществ:

  • Создать выделенный сервер будет проще, так как любой код, который будет отображаться, будет в одном месте.
  • Вы можете отделить свою updateфазу от своей renderфазы и запускать их с разными временными шагами.
  • Вы можете убедиться, что ваш код рендеринга не изменяет игровое состояние, используя const, уменьшая количество ошибок.

1
+1 Я не могу больше согласиться с этим мнением. Отделение моделирования данных от визуализированных представлений этой модели позволит вам аккуратно выполнять аккуратные вещи, такие как множественные окна, которые отображают различную информацию, переносить рендеринг на другие платформы, добавлять анализ и настраивать симуляцию для игрового процесса без необходимости прикасаться к 90% базы кода. ,
Патрик Хьюз

5

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


+1 Я склонен с этим согласиться. Если на сервере будут запущены какие-либо клиенты, то он должен делать это как отдельные процессы.
инженер

5

Разделение проблем FTW, как уже говорили другие, но если ваша конечная цель состоит в том, чтобы иметь отдельные клиентские и серверные приложения, вам нужно сделать еще один шаг вперед. Вы должны определить, что является специфичным для клиента, что является специфичным для сервера и что является общим. Для всего, что является общим, разделите его на классы исключительно общего кода; Специфичные для клиента или сервера классы могут затем создавать подклассы или ссылаться на общие классы в зависимости от ситуации. Переместите разделяемые классы в отдельный проект, создав JAR «разделяемой библиотеки», и включите этот JAR в проекты клиента и сервера.

У этого есть несколько преимуществ: это делает разделение интересов кристально чистым, чтобы все было в отдельных проектах; он гарантирует, что клиент и сервер начинают с одного и того же общего кода (при условии, что они используют одну и ту же версию общего JAR-файла); и это делает невозможным «случайное» изменение общего кода, не осознавая этого. Если общий код находится в его собственном проекте, вы будете знать, когда будете редактировать что-либо в этом проекте, что вам необходимо знать, как изменения повлияют как на клиента, так и на сервер.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.