Хранение игровых объектов
 

Здравствуйте, расскажите пожалуйста, как можно эффективно хранить информацию об игровых объектах. Скажем, набор транспортных средств, вооружения и т.п. Может XML?

Что серверу удобней читать - в том и хранится. Обычно это xml или тупо база данных. Во втором случае клиент получает _справочную_ информацию только через запросы к серверу или через сгенеренное в xml/amf из базы специальным скриптом.

Второй момент - в чём удобнее редактировать _справочную_ информацию геймдизу. Геймдизу удобнее это делать почему-то в xls (Microsoft Excel) (ну и громко орать "Я правлю справочники, не трогать их!" перед началом изменений, потому как формат бинарный и мержить его придется вручную :)). Соотвественно, если геймдиз посылает Вас подальше с предложением править xml или базу через php myAdmin - Пишется генератор xml из xls или специальный самопальный редактор заточенный под конкретную игру (но последнее слишком дорого)
А, еще некоторые справочные данные (например размеры объектов, их расположение) даже в xls редактировать не удобно и для них пишется одтельный редактор. Принцип простой: данные нужны серверу - генерируется xml, данные нужны только клиенту - amf.

Ну ещё, если кто работал с серверистами-фанатами кодогенерации - может расскажет про генерацию классов на as3 с описанием объектов и для php/C#/Java/ruby для полной синхронизации с клиентом.

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

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

Да ну что вы. Еслиб я был геймдизом и услышал такое от прогера - послал бы его лесом. Это же надо сначала в xls сохранить, а потом экспротнуть в csv - что за дикость? Да и на самом деле щас есть либы, которые очень шустренько парсят xls, как-бы сложность написания генератора не высока. Проблема в самом факте генерации, т.е. вместо "поправил xml" получается "поправил xls, нажал шоткат генерации", и он не мержится. Но это можно пережить, а с мержингом - кроме 1,5 геймдиза обычно туда никто не лезет и мержить этим 1.5 -геймдизам приходится редко, хотя болезненно.

Т.е. экспорт в *.csv не решает никаких проблем - только добавляет лишнюю операцию експорта.

Веселее с локализацией - ёе правит куча народу одновременно, а переводчики, будь прокляты пираты, подсадившие всех на Microsoft Office, кроме xls ничего не воспринимают. В итоге пришлось идти на компромис - клиентская, самая часто правлимая большим количеством народу хранится в tab-separated text - формате (там формул нет, xls не нужен), легко мержится, правится спец-редактором без всяких перегонов в xls, но при отдаче переводчикам - копипастится в xls(tab-separated text копипастится в Excel просто, хотя нужно проявить внимательность, чтобы не затереть полученным от переводчиков новые ключи, добавленные во время ожидания перевода). Так оказалось наиболее удобно.

По поводу xml vs json - мне тоже json больше нравится. Да вот проблема - с текстом он не очень дружит - вместо <![CDATA[]> пишутся дикие escape-последовательности. Да и json - это не mainstream, все поголовно выбирают xml. Как-бы миллионы разработчиков не могут ошибаться. Ещё, при сильном желании (пока не пробовали) xml можно валидировать с помощью схем. Это гораздо более мощный формат.

Какие миллионы разработчиков то? Я пока что ни с одним не знаком кто предпочел бы хмл джейсону.

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

А формулы? Пропадут ведь (они же ещё свои дизайнерские заморочки там рассчитывают). А геймдизы, будьте уверены, нужной квалификации соотвествуют. Ещё они там basic-скрипты, подсвечивающие циферки нужными цветами сохраняют, форматирование какое-то ещё, помогающее ориентироваться.

А я фанатов json не встречал. Сами, кстати, не натыкались на проблемы с текстом в json-е или исключительно через спец-админку правите?

А любом случае я за адекватную админку, а не за ексель. И те же геймдизы спасибо скажут.

Так то да, несмотря на то, что немаленькие проекты писали в xls - иногда стонут и просят редактор, ибо тяжело вписывать смежные айдишники с разных таблиц. Но не понятно, как они после этого своими расчетами будут заниматся. Да и вообще не понятно окупится ли время на эту админку, которая будет помогать соблюдать согласованность данных (типа помощи от автокоплита в IDE).

Можно, конечно, сделать чтобы админка изменяла xls и читала xls, чтобы и рассчетами можно было заниматся и править где удобнее. Но ситема
Это уже перебор в терминальной стадии. XLS надо выкидывать. Но смогут ли отказаться геймдизы от расчетов? Жаловаться то на отсутвие админки/редактора они умеют.

Можно так, конечно:
Но всё равно из таблицы xml достать не сложно, а загнать логические данные в таблицу и не повредить форматирование с формулами - уже непростая задача.

Интересно в этой связи о Вашем опыте использования админок и геймдизов услышать.

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

Для социалки это много. Не окупится.

Но всё-таки: На чём, по каким принципам его пишете/писали бы?
Самое логичное (в моей голове):
- пишем на air чтобы использовать готовые классы из as3-клиента
- сохраняем в тот же xml/json и читаем из того же xml/json, что будет использоваться сервером
Вроде локально править xml/json и сохранять в репозитории удобнее, чем через web-приложение -не?

Просто меня термин "админка" вместо редактора смущает. Использовать web-админку но зачем? Что вы под админкой подразумевали?