Я хочу створити текстовий MUD, тому багато елементів рамки XNA здаються відповідними тому, що мені потрібно. Особливо такі речі, як загальний цикл ігор, мережа тощо. Схоже, XNA тісно поєднаний з інтерактивним середовищем з інтерфейсом користувача та аудіо, тому я не впевнений, чи це правильний шлях.
Чи було б простіше просто відтворити такі типи аспектів, спробувати прив’язати рамку XNA до того, що мені потрібно, чи є краща рамка для цього виду роботи?
Відповіді:
Я не думаю, що рамка XNA не запропонувала б вам великої користі для серверної частини текстової гри, ні. Ви повинні подивитися стандартні бібліотеки базового класу .NET для цього випадку використання.
Але трохи розширивши питання, хоча рамки XNA дійсно призначені для розробки ігор 2d та 3d ігор, можливо, є причина використання частин їх на стороні сервера 2d або 3d гри. Звичайним є повторне використання частин графічного двигуна на сервері, оскільки сервер повинен робити такі дії, як тестування на видимість та зіткнення так само, як і клієнт. У такому випадку, якщо ваш двигун використовував математичну бібліотеку від XNA, вам потрібно буде також пов’язати це з кодом вашого сервера.
Якщо ви використовуєте C #, вам слід просто розглянути можливість використання WCF для відстеження мережевого шару. У MUD не було б великої кількості мережевого трафіку, відносно кажучи, тому проходження цього маршруту може полегшити вам справи. Я використовував WCF для покрокової стратегічної гри, і для мене це досить добре розроблено.
telnetінтерфейс може мати сенс бути шаром поверх більш надійного API, наприклад, побудованого на WCF.
Ви можете пройти маршрут XNA і просто використовувати конкретні елементи, які ви бажаєте (аудіо, мережа тощо); але це збільшує складність вашого проекту та зменшує ваше «негайне розуміння» бази коду.
В основному, якщо ви додаєте більше середнього програмного забезпечення, ваші знання про те, як працює ваш код насправді, зменшуються - якщо ви не заглиблюєтесь у реалізацію проміжного програмного забезпечення. Коли ви віддаляєтесь, ви втрачаєте працездатність, здібності та розуміння.
Отже, як зазначено вище, вам було б набагато вигідніше використовувати C # та відповідні бібліотеки, що не мають XNA.
Якщо ви робите це для власного зведення, ви можете також прокласти своє місце, де вас цікавить область - ви дізнаєтесь більше цього.
Действуй! Веселіться!
Це багато в чому залежить від ваших вимог.
Якщо ви зацікавлені в підтримці аудіо, запрошує друга, тощо, я вважаю, що XNA - це шлях.
Основним обмеженням, з яким ви стикаєтесь при використанні XNA для мереж, є обмеження гравця в 32 гравців на гру.
Коли ви розробляєте гру з рамкою XNA, не обов'язково з'єднуватися з усіма різними API. Багато людей використовують рамку XNA, але покладаються на інші рамки для створення мереж.
Моя пропозиція полягає в тому, щоб фізично (записати їх у блокнот чи щось таке) перелічити ваші потреби та потреби щодо аспектів мереж. Потім порівняйте та порівняйте різні рамки.
Я схиляюся до того, щоб сказати "створити з нуля", але це просто відчуття кишки, засноване на тому, що працювали з C # та MUD кодом окремо. Ви матимете більше контролю та дізнаєтесь більше про прокручування власних версій того, що ви, можливо, зможете використовувати від XNA у будь-якому разі.
З якоїсь причини ви не використовуєте існуючий двигун MUD, принаймні для довідок?
telnetз'єднань. Для звичайних текстових MUD-файлівtelnetдається можливість доступу користувачів до сервера.