Извините, ничего не найдено.

IGR · 02.04.2011, 03:29

+1, да можно и на юдп навернуть свою систему уведомлений и перепосылок !! Но вопрос в другом а стоит ли ??
Если игра не динамичный шутхер то лучше не "чудить" а брать сразу тсп !!

moka · 02.04.2011, 03:56

На деле, udp с механизмом уведомлений по скорости будет то же самое что и tcp, при этом количество клиентов будет не превышать нормальную архитектуру, ту же IOCP к примеру.

DStalk · 13.05.2011, 21:03

Добрался до PureBasic`a, начал переносить сервер с блица, все вроде норм, но есть несколько вопросов:

1. Пробую мультитреадинг. Наверно поставлю в отдельных тредах процедуры логина, обработки игроков и обработки монстров (3 треда). Вопрос насчет базы данных, надо ли синхронизировать треды, например чтобы не было одновременного доступа к БД?

2. Нормально ли будет, если я например информацию о нужном в данный момент предмете буду запрашивать из БД, или стоит информацию о предметах подгружать в память (переменные, массивы) при старте сервера?

3. Использую SQLite базу данных. Друзья подсказывают, что в некоторых случаях она быстрее MySQL. То что к ней не будет доступа например с сайта для меня не проблема. Что скажут по этому поводу булочники?

Какая БД лучше?

moka · 13.05.2011, 22:19

1/2. Вообще доступ к БД, должен выполнятся редко. И может быть с разных потоков. Логика по сути не должна к БД относиться вообще, т.к. её задача - обработка логики.
Менеджер информации, должен отвечать за то что должно быть загружено в ОЗУ, а что нет. Логика работает с данными из ОЗУ, значит они должны быть загружены. Например вещи выставленные на аукцион - должны быть в ОЗУ. При их покупке и т.п. естественно обновлять БД и т.п. Но не выгружать из ОЗУ.
Тут важно понимать, что должно использовать данные и от куда.
По идее, бд - лишь для хранения данных, но никак не для логики и т.п. Всё должно быть в ОЗУ. Те же мобы, они вообще никакого отношения к БД например не имеют. Либо те же вещи, они почти везде и всегда будут в ОЗУ, таким образом нету никаких ссылок к БД.
Вынеси загрузку из БД в отдельный механизм.
Например шмотьё, есть вещи, с которыми может взаимодействовать только персонаж который их имеет, например баночка. Держать эту инфу не нужно в ОЗУ, если этот персонаж не в игре. Если он в игре, то грузить всё с ним связанное.
При этом есть такой момент, вещь может принадлежать игроку, но быть на том же аукционе, таким образом с ней могут взаимодействовать. Получается она должна быть в ОЗУ всегда, даже если её владелец не онлайн. А это реализуется простым списком вещей для аукциона, который есть в БД и в ОЗУ. Таким образом если вещь купили, то её нужно изъять у игрока который был владельцем, если он оффлайн, это делается через БД, и тут нужно быть уверенным что он сейчас не заходит в игру, чтобы не возникло конфликтов, изъятия его шмотки и загрузка её же. По сути, каждая шмотка также имеет уникальный ID, и т.к. она была куплена другим, то тут тупо при загрузке, нужно проверять, не загружены ли эти вещи уже в ОЗУ, если да, то не грузить и т.п. Там куча условий и сценариев на которых можно наколоться.
Поэтому нужно организовать работу с БД и данными в ОЗУ, очень корректно и как весьма мощный механизм.

3. Раньше склонялся к MySQL, но сейчас использую везде MSSQL, намного шустрее выходит, и удобнее с ней работать. Плюс удобный манаджер (визуальный), и другие плюшки относительно самого Query языка.

HolyDel · 14.05.2011, 09:30

и тут нужно быть уверенным что он сейчас не заходит в игру, чтобы не возникло конфликтов, изъятия его шмотки и загрузка её же.

транзакции же. все критические запросы на изменения данных тока в тразакциях. надо не переборщить.

Раньше склонялся к MySQL, но сейчас использую везде MSSQL

вот под этим подписываюсь полностью

pax · 14.05.2011, 10:47

Кстати кто может сказать, для серверной части критичным будет использование LINQ to SQL например? Я вот подумываю попробовать для старта использовать компилируемые LINQ запросы. Если уж производительности не хватит - то перевести серверную часть на обычный ADO.NET.
Просто сейчас критичным является срок разработки...

pax · 19.05.2011, 20:54

Подскажите кто что думает вот о такой архитектуре. Если есть комментарии/замечания, то буду очень рад:

Нажмите на изображение для увеличения
Название: MMO.png
Просмотров: 1038
Размер: 102.9 Кб
ID: 13810

Оговорюсь сразу - MMO подразумевается по ходовое.

IGR · 20.05.2011, 00:35

как по мне - решение имеет право на существование !!

pax · 20.05.2011, 14:15

Ну может есть у кого предложения по улучшению, лучшей организации или какие-то рекомендации? У меня опыта в MMO - 0%) я даже в них практически не играл )

moka · 20.05.2011, 19:39

Что такое Realm?
В моём понятии это сервер, что имеет свою DB и свою независимую игровую логику.
Это в случае если предусматриваются разные сервера, для разделения игроков, возможно по режимам игры (PvP/PvE или т.п.), также они естественно могут иметь разные настройки, и возраст, который будет определять уже общий коэфицент развития игроков в игровом мире.

Получается нужно иметь отдельный сервер, что будет иметь DB всех учётных записей, также этот сервер будет отображать статус realm'ов, и т.п.

Когда user заходит в Launcher, он логиниться под его учётной записью, затем ему выдаётся список серверов, и их статусы.
Он выбирает realm на который заходить, на этом моменте он устанавливает соединение с выбранным сервером, и далее уже получает список персонажей.
При выборе персонажа, идёт уже загрузка в мир, исходя из локации, и т.п.

По сути, первый сервер, имеет ответственность за авторизацию игровой копии (если такое предусматривается), а также аутентификацию учётной записи.
Также, при соблюдении всех проверок, и выборе реалма, должен создаваться временный ключь сессии, на этом же сервере. Который будет запрошен и сверен с предоставленным от клиента. То есть: при выборе realm'а, на сервере учёток создаётся уникальный ключик (хашь хрени всякой), шлётся пользователю, пользователь с этим ключём посылает запрос на realm, который в свою очередь ищет по этому ключику сессию на учётном сервере, находит, и таким образом, он знает уже какой пользователь (учётка), и т.п. соединяется. Этот ключик сессии, должен быть деактивирован каждый раз при дисконнекте, и он же будет участвовать в проверке попытки зайти два раза тем же персонажем, и для логов.

Учётный сервер, сильно отличается от игрового.

Игровой сервер уже будет осуществлять всю игровую логику.
Далее, технически, нужно иметь статус состояния клиента на сервере, исходя из которого, будут ожидаться те или иные пакеты с данными. Так сказать, инкапсулировать логику на приём пакетов, которые не должны ожидаться.

Учти, что внезапный обрыв клиента, должен быть ожидаемым в любой момент, и с этим придётся считаться, чтобы "замести" все следы недоделанных работ.

Работа с БД, должна также быть весьма отделённой от игровой логики. Почти вся игровая логика должна быть завязана на данных в ОЗУ, а менеджер загрузки данных, должен грузить и выгружать чётко что нада а что нет.

Тут будет много парки с утечкой памяти.
Также, учитывай, что сервер может вдруг упасть, все данные, будут потеряны (те что в ОЗУ), и с этим нужно тоже считаться..

pax · 21.05.2011, 02:41

Спасибо за комментарий!

Realm - это игровой мир, я не думаю что они будут различаться функционально, просто несколько миров или один и тот же мир.

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

Вот я не думал что для всех серверов стоит разделять базу данных... сейчас что-то задумался...

moka · 21.05.2011, 04:17

Если это отдельный мир, и игрок имеет возможность зайти тем же персонажем на другой realm, тогда разделять БД не нужно на realm'ы.
Либо если это организовать грамотно, тогда будет выгода, т.к. количество записей в таблицах будут в разы меньше, т.к. делены на realm'ы, но нужен тогда сервис транспортировки туда-сюда.

Вот интересно то что в том же WoW, есть Battleground'ы, это типо становишься в очередь, далее сервер ищет команды 10 либо 15 либо 30 (зависит от бг), и затем когда начинается игра, запускается бг, но прикол в том что игроки на бг, с разных серверов, а не с того же. Таким образом за БГ, отвечает отдельный сервер, который собирает инфу с разных бд серверов.
Но там всё сложно, там целые cloud'ы в дата центрах, там всё реально сложно

Хотелось бы знать больше о ТЗ, относительно учётных записей пользователя, realm'ов, и самих персонажей..

pax · 28.05.2011, 18:52

Да пока больших ТЗ нет. Просто конструирование обобщенной архитектуры.

moka · 28.05.2011, 20:15

Также, соединение/отсоединение, не должно иметь важных процессов, т.к. нормальное соединение/отсоединение на основе сообщений "игрок_выходит" и типо того, они не обязательно будут всегда. Я могу тупо сделать Clt+F4, такие образом нужно меньше всего зависеть от наличия игрока подсоединённого. Это говорит также о разделении самого клиента с точки зрения сети, так и клиента, с точки зрения игровой информации.

Мыслей куча, большинство конечно будут весьма очевидными, но если будут конкретнее вопросы, то с радостью поделюсь размышлениями.
ЗЫ, сейчас свой ассинхронный сокетный сервер, переписываю

Хотел реализовать повторное использование сокета, не удалось, он остаётся заbind'еным, а это не позволяет снова его использовать..

Если стретитесь с этим, буду рад услышать про это.

Также сделал в локальной сети стресс тест, запустил сервер, на простеньком компе (4гб рама, старый проц), и далее на трёх разных компах запустил по несколько клиентов. Каждый клиент создавал каждый 2мс подключение к серверу, всего он делал 1000 подключений, и затем, каждые 100мс, он слал с каждого подсоединения по 1 биту.
Сервер же, принимал подключения и ставил сокеты на прослушку, принимал сообщение и продолжал слушать каждый подключенный сокет. Также в течении секунды рассылал всем по 1 биту пакет.
В итоге, я позапускал около 20 клиентов на трёх разных компах.
Сервер выдержал без проблем 20 000 подключений, и слал пакетики. Проц вообще не грузило, когда все были подключены.

pax · 30.05.2011, 17:41

Первый вариант асинхронного клиент-сервера с бинарной сериализацией пакетов заработал успешно )
Будем дальше пробовать сеть программировать. Начнем с сервера получения игровых сессий.