Запуск і сервера, і клієнта в межах одного процесу

Питання

Я тільки вперше почав працювати з Lidgren та мережами, і я зрозумів, що можна запускати і сервер, і клієнта в межах одного процесу.

Чи відштовхується ця практика з якоїсь причини?

Контекст

Причина, про яку я питаю, полягає в тому, що я теоретизував, що ця концепція може мені дозволити трактувати як одиночний, так і багатокористувацький режими як один і той же, що було б дуже корисно.

Слідуючи моїй думці, це я мав на увазі розподіл:

• Singleplayer - 1 сервер + 1 клієнт в одному процесі. Наскільки швидкі комунікації?
• Мультіплеер - Те ж саме , як одного користувача для хоста + 1 клієнта для послуги для покупців кожного іншого гравця.

Я зображую потік виконання, щоб клієнти отримували введення користувача та надсилали повідомлення на сервер. Потім сервер перевіряє його і транслює дію, яку слід виконати всім клієнтам. Не має значення, чи є лише один клієнт (тобто однокористувацький) або кілька клієнтів (тобто багатокористувацький).

Це в основному питання щодо питання проти потоку, обидва не надто відрізняються, іноді нитки називають легкими процесами. Найбільша різниця полягає в тому, що окремий процес має власний адресний простір, але є й інші відмінності (1):

За процес

• адресний простір
• Глобальні змінні
• Відкрити файли
• Дочірні процеси
• Очікують тривоги, переривання та обробку сигналів

За нитку

• Лічильник програм
• Реєстри
• Стек
• Держава

Виходячи з цих відмінностей, було б зручно мати сервер і клієнтську нитку в одному і тому ж процесі, щоб ви могли обмінятися ручками файлів і глобальними змінними. Це було б аргументом для підходу "в тому ж процесі", іншим (малим) аргументом буде те, що ви отримуєте лише одне спливаюче вікно "Брандмауер Windows" за один процес. Аргументом для підходу "іншого процесу" є те, що людина може запускати кілька серверів, не запускаючи декількох клієнтів. Це було б ідеально для завзятого хоста, як налаштування, і це підхід, який ми часто бачимо у шутерах від першої особи.

Що ж стосується ідеї мати серверний процес або нитку навіть для гри в режимі офлайн (а може навіть для однокористувача), то це чудова ідея, яка багато використовується на практиці. Ви можете сказати, що багато ігор роблять це, дивлячись на екран завантаження, невеликі підказки, як-от "отримання", видадуть це. Це логічно зробити, оскільки якщо ви збираєтеся зробити багатокористувацьку, більшість ігрових правил буде керуватися сервером, так чому б вам не керувати ними для однокористувача? Це зменшує код, який потрібно писати, і дає чіткіше розділення між клієнтом та "грою", що покращить якість вашого коду.

А як щодо спілкування між процесами та потоками? Перехресне спілкування між процесами можна здійснити багатьма способами (з назвою), спільною пам'яттю, COM, це дійсно залежить від технології, яку ви використовуєте. Однак якщо ви робите сервер, ви, ймовірно, захочете скористатись мережевим варіантом, використовуючи сокети і щось подібне до TCP, це, звичайно, LIDGREN стане в нагоді.

Дуже багато цих прийомів справедливі і для комунікацій поперечних потоків. Але це ще більше залежить від методик, якими ви користуєтесь. Ви знову можете перейти з TCP, але, можливо, ще простішою системою були б події та деякий маршал, хоча це може зробити ваш цикл гри недетермінованим (2).

Джерела

1. Проектування та впровадження операційних систем (книга MINIX), 3-е видання Ендрю С. Таненбаума
2. Виправте часовий крок за Glenn Fiedler: http://gafferongames.com/game-physics/fix-your-timestep/