Покрокові посилання на сервер настільних ігор? [зачинено]

Чи є якісь хороші довідники / книги, які можна рекомендувати щодо того, як створити покроковий ігровий сервер? Це щось на зразок шахового сервера для сполучення шахістів та збереження ігрових станів. У минулому, наприклад, IGS (for go, weiqi) - це реалізація на основі сокета. Які доступні сучасні технології навчитися? Дякую!

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

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

Спарювання ppl можна зробити через Elo ... але я думаю, ти знав це

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

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

Вам потрібен якийсь тип звітів між поворотами, наприклад, "Гравець 2 переміщує одиницю" або "Ваш опонент може бути АФК"? Якщо так, то, можливо, ви захочете зберегти розетки.

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

Редагувати: Якщо гра підтримує лише ігри «1 на 1», можливо, варто звернути увагу на однорангові з'єднання.

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

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