Як ви дозволяєте записати мережевий код на пізніших етапах розробки?

Наразі я перебуваю на ранніх стадіях написання гри, яку, врешті-решт, захочу вдосконалити в більшості аспектів.
Як я можу пропустити написання мережевого коду, але залишаючи його досить легко реалізованим, тобто не потрібно переписувати всю гру лише для того, щоб додати її.
Що я маю пам’ятати?

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

Редагувати: планується бути RPG зверху вниз. Про те, що я думаю, простий мультиплеєр, де ви розміщуєте сервер для своїх друзів, тож обман - це не велика проблема (хто хотів би пограти з друзями, які обдурили?). І все-таки я хотів би перейти з "Сервер завжди правий" - підхід.

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

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

Однак ви можете розглянути це рішення, яке ви приймаєте, залишити код мережі до кінця, залежно від того, наскільки важливою є мережа для вашої гри.

Я маю на увазі те, що якщо ви пишете важку мережеву гру, таку як MMORPG, можливо, не розумно залишати мережу до кінця.

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

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

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

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

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

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

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

Мій підхід узгоджується з вашим коментарем щодо IPC (міжпроцесорний зв’язок).

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

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

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

Якщо ви дізнаєтесь про всі ці речі, чому б не написати просту програвач для версії 1 для однокористувача, і коли це буде працювати, з вашими глибшими знаннями, переосмислити все це за версією 2, яка буде багатокористувацькою?

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