www.mudconnector.su

Нет, конечно, это неправильно. Чистить всем мозги при ребуте.

Про СУБД могу вот чего сказать из практики: сегодня ночью, часа за два всего, переехал на MySQL. Переезжаю кусками, поэтому пока включено только создание персонажа/логин и движение. Скорость вполне ничего, кстати, разницы я не заметил. В воскресенье будет, надеюсь, полная версия, опишу впечатления. Работать с БД стало удобней, по большому счету потому, что всякие методы #save, #find etc упрятаны в чужой модуль. Также сразу работает магия типа some_room.creatures, some_creature.items и другое.
Только надо включить "ленивый" update, чтобы только измененные атрибуты писались в базу и тогда не будет проблем со статикой типа имен и прочего.

Не знаю вообще как можно начинать тему выбирая бд против сериализации и тем более говорить о хранении часто используемых данных в XML. Почему не XML - ну вы что издеваетесь, часто читать записывать файлы и напрягать сервер работой парсера и проверкой валидности файла. Второе. БД и сериализация как бы разные вещи и как бы цели у них желательно разносить не будем забывать что бд работает с фс и это вполне тяжелое приложение чтобы в него постоянно писать такие мелочи как изменение положения игрока и подобные глупости. Это же какая дикая нагрузка. Как раз для хранения таких вот часто или очень часто меняющихся вещей стоит использовать сериализацию. Причем для активно изменяющихся объектов можно не проводить сериализацию. Для часто используемых повторяющихся данных можно использовать сериализацию и хранение в memcache или redis к примеру. И только относительно редко использующиеся объекты можно записывать в файл. Таким образом часто используемые объекты всегда в памяти, либо в памяти приложения либо в сервере мемкэш. Реже в файлах. А статические или очень редко меняющиеся типа уровень персонажа, карта без объектов, прототипы мобов или подобное хранить в бд. И записывать туда периодически дамп состояния. То есть актуальнее к примеру будет опыт персонажа в памяти сервера игры или мемкэше, и периодически это значение можно обновлять и в бд. Некая мини резервная копия. Таким образом и нагрузку с бд снимете, фрагментация ниже будет, ну и соответственно нагрузка на фс ниже. Единственный компромисс использования бд для часто используемых объектов - скьюлайт в памяти. Но это данные часто меняющиеся, и скьюлайт тут для удобства пользования.

Вот тут я вижу собралось много народу... умного.
Вопрос простой: вы не рано-ли задумались "о проблемах" ?
Вы где СТОЛЬКО игроков собрались взять, чтобы любая, даже
самая дубовая реализация на самых дубовых железках тормозила ?

С 100+ человек онлайн пентиум2 выгружал все данные раз в Х минут
без какого-либо напряга для окружающих...

Представляете какие были диски итп в то время.

Лично мое мнение "по проблеме". Делать слепки "всего" периодически.
Достаточно раз в Х минут. Вполне.
В каком виде их хранить - не важно абсолютно.
Яб хранил "в файлах" по многим причинам.

Во первых это мое ИМХО и я не претендую на решение серебряной пули. Я лишь пытаюсь представить модульный сервер, с возможностями оптимизации, наличие которых лучше чем их отсутствие. Во вторых хранение многих файлов очень сильно снижает скорость работы фс. В третьих, на дубовом железе кроме как связка си плюс файлы ничего нормально и работать то и не будет. Знаем, плавали. На старом железе сервера баз данных просто замечательно тупят. Ну и вообще. Лучше предусмотреть хотя бы интерфейсы для быстрого расширения и добавления оптимизации. Лучше предусмотреть заранее. Ведь освобожденые ресурсы можно пустить на какие то тяжелые фишки для игры. К примеру реалтаймовая экономика мира. Настоящая, а не бесконечные деньги у торговца. Или еще на что нить. Всегда найдутся вещи которые потребуют ресурсы. Так не лучше ли предусмотреть это заранее

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

Не лучше.
Все беды при разработки программного обеспечения от бессмысленной преждевременной оптимизации.
Работа с хранением данных просто должна быть локализована. А уж где хранить, поверьте мне 99.99% проектов будет "пофиг".

Касательно "реалтаймовой экономики" и "прочих фишек". У вас есть блок-схема-алгоритм необходимых вычислений ?
Да, или нет ? Нет, или да ? Потому как в 9 случаях из 10 всё упирается в её отсутствие...

Мады с 100+ онлайн вполне комфортно по производителоности работали на железе 10летней давности.
Стоит ли думать в первую очередь о производительности дело бесспорно "каждого".

Зачем ? Это основной вопрос.
Как все эти "фичи" повлияют на игрока ?

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