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

[PlutDem]

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

[expl]

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

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

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

[Dukobpa3]

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

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

[expl]

если научить его сохранять свои таблицы в *.csv, то, в принципе, несложно из этого самого цсв импортировать куда угодно.
Да ну что вы. Еслиб я был геймдизом и услышал такое от прогера - послал бы его лесом. Это же надо сначала в 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 можно валидировать с помощью схем. Это гораздо более мощный формат.

[Dukobpa3]

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

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

[expl]

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

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

[Dukobpa3]

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

[expl]

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

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

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

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

[Dukobpa3]

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

[expl]

недельки за три сварганить
Для социалки это много. Не окупится.

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

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

[Dukobpa3]

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

И что значит "вместо редактора"? Есть редакторы, для разных целей. редактор под одну задачу пишется ну может день-два от силы. Домики там по карте расставить или еще чего. А админка это админка.

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

Выбор инструмента разработки в любом случае ложится на вас(команду), а там уж как удобнее. Скилл того кто будет писать имеет не последнее место в оценке. И если ему приятнее луа, или хасп - пусть пишет на нем. Задача не суперсложная чтоб глубокую оценку адекватности/неадекватности технологии вцелом оценивать. Та и мое мнение - все технологии глобально одинаковы. С чем умеешь с тем и работай.

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

Добавлено через 2 минуты
И вот допустим в чем прикол самописной админки - удобство геймдиза. Например можно добавить функцинал "добавить сто объектов, у которых будут такие то параметры, и у которых вот этот параметр друг от друга будет оличаться по вот этой вот формуле". На петоне такой плагинчик пишется минут 15, а ГД потом будет крайне счастлив это использовать.
В ексель такой макрос тоже можно всунуть но это уже не тот результат будет и там не настолько удобно этим управлять.

[expl]

Спасибо за ответ. Теперь остается дальше думать писать её или не писать.

Мы писали на петоне и база была в файликах джейсона. Но если ли бы писал я сам - то скорее всего это тоже был бы ейр, банально потому что я ас3 знаю лучше петона. В текущей конторе админка на шарпе написана, и работает с МСскуль.
Использование готового кода, который описывает объекты из игры не так важно получается.

[Dukobpa3]

использование готового кода это изначально бред. Код должен быть в проекте, а не в базе данных. (собственно я очень удивился при упоминании <CDATA[]>)

[expl]

(собственно я очень удивился при упоминании <CDATA[]>)
Это я к вопросу о ручной правке xml и json и о том как тяжело было бы править тексты в json (у нас был один проект, в котором вручную правился xml) Искользование кода тут как-бы не причём.

Про использование готового кода:

Вот в игру встроен валидатор справочных данных (просто показывает на старте все нестыковки в справочнике, чтобы потом не обрабатывать эти возможные нестыковки данных в остальном коде). Вот чтобы геймдизы не заливали каждый раз на сервер xml - пишется валидатор. Код валидации уже есть. Т.е. написал выбор и загрузку файла с отображением результатов - и всё! Валидатор готов. И при изменении валидации его нужно только перекомпилировать - он ведь использует код игры.

С админкой/редактором, конечно не всё так просто, но почему там готовый код помогать не будет?

[Dukobpa3]

потому что эти данные используются и на сервере и в клиенте. И валидаторов придется делать два если с таким подходом. А так пишется один валидатор работающий по общим законам и проводит проверку при сохранении, если косяк - тупо не даст сохранить изменения. Наоборот проще получается. Данные невалидные до твоего клиента тупо не дойдут равно как и на сервер.

[PlutDem]

Собственно, я спрашивал потому что у меня все типы игровых объектов были "захардкодены", а это, насколько мне известно, очень и очень плохая практика. Выбор остановил на XML, все же он чаще используется как раз для таких целей, да и выглядит не страшно:)

Теперь вопрос состоит в том, как хранить игровые объекты при выполнении приложения. Т.е., например, объект Машина имеет какие то свои характеристики как тех.состояние, пробег, местонахождение и характеристики определяющие ее тип или модель. Скажем что это Камаз, у него такие то габариты, столько то колес и др. Т.е. по сути это классы и их реализации, но как быть если описание модели машин берется из вне? Парсится из XML, к примеру? То есть, нужно создать какую то структуру данных для хранения характеристик игрового объекта, на которую ссылались бы все реализации?

[Dukobpa3]

МВЦ.
Модель грузится снаружи, парсится в свой формат(Парсится и заполняются параметры класса модели), а в проекте ты описываешь контроллер и вью.

[PlutDem]

Dukobpa3
Т.е. вы предлагаете создать модель в которую заносятся данные полученные парсингом, а экземпляру дается идентификатор, по которому он может получить из модели связанные с его типом данные?
Если да то как это можно грамотно реализовать?

[Dukobpa3]

Я не знаю как объяснить еще.

В ХМЛ хранятся такие параметры как:
- цвет машины
- скорость
- кол-во колес
- ид ассета
- прочая ботва

Просто как набор полей в базе данных. Кода тут нет.

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

- Ты грузишь с сервера хмл,
- заполняешь класс модели.
- И после этого у тебя есть некий инстанс модели var _kamaz:CarModel, который уже имеет установленные из ХМЛ параметры, но плюс к этому и код, который собственно и прописан в этом классе, некий функционал и логика.

Добавлено через 1 минуту
Грамотно можно по-разному. Я не видел проекта, и не знаю всех требований. Конкретные решения лучше по месту принимать, и они будут отличаться для каждого проекта. Панацеи нет и быть не может.

[Bgg]

Зачем пугать сразу MVC?

public class Car{
private var _color:uint;
private var _speed:int;
public function Car(xmlFromServer:XML){
_color = xmlFromServer.color;
_speed = xmlFromServer.speed;
}
}

Кстати, не только про хранение данных, но и про написание скриптов: http://gamedev.stackexchange.com/questions/33453/how-smartly-implement-scripting-in-game

[Dukobpa3]

Зачем пугать сразу MVC?
Ну вариант когда данные лежат в базе на сервере это уже и так мвц:)
- сервер - контроллер
- база - модель
- клиент - вью
:)

Почему бы просто не называть вещи своими именами.

[PlutDem]

Dukobpa3
CarModel- один класс-болванка для одного типа машин, а как быть если этих типов несколько несколько?

[Dukobpa3]

Вариантов жеж куча, можно болванку написать так что она под все машины подойдет.
А можно эту болванку екстендить уже разными типами и там уникальные штуки попрописывать, которые не вписываются в "ездить и жужжать".

[PlutDem]

Dukobpa3
Не, я не о том. Вот спарсили мы одну машину и запихали ее данные в CarModel, а куда девать остальные машины? CarModel-то один. Понаделать болванок про запас - не вариант.

[Dukobpa3]

Че-то я вообще вопроса не понимаю.

[t4arty]

используйте интерфейсы, и модели машин могут быть разные, а то что есть у всех машин будет и в интерфейсе

[PlutDem]

Dukobpa3
На сколько я понял, у нас есть только один класс CarModel. В XML описано несколько видов машин: зеленая, красная, синяя и тп. Парсим XML, вытаскиваем данные зеленой машины и запихиваем их в CarModel. Болванка-CarModel по сути стала зеленой машиной. Можно было бы уже праздновать, но у нас на очереди еще красная, синяя и др. машины. Как быть с ними? В CarModel уже лежат данные зеленой машины, куда пихать данные оставшихся машин? Как уже говорил, понаделать болванок про запас - не вариант. Хотелось бы, что бы при инициализации приложения, XML парсился и из него вытаскивались все виды машин какие там описаны.

[Dukobpa3]

Если ты не понимаешь разницу между классом и экземпляром класса - я зря тратил всё это время.
Кури мануалы.

Добавлено через 1 минуту
var _kamaz:CarModel = new CarModel();
var _greenSedan:CarModel = new CarModel();
var _yellowCoupe:CarModel = new CarModel();

[PlutDem]

Dukobpa3
Так вы предлагали в экземпляр класса CarModel заносить данные? Тогда понятно. Я просто думал, что данные будут копироваться в статические свойства класса CarModel и тогда, собственно, его экземпляры и будут опр. типом машин. Если так, то ваш способ мне все равно не подходит, так как, машины не ссылаются на свои данные существующие в единственном экземпляре, а хранят их у себя. Т.е. поменять скорость у всех Камазов изменив в одном место свойство, уже не получится. К тому же вечно дергать парсер- очень накладно. Нужно раз спарсенные данные сохранить в памяти в каком либо виде, что бы иметь к ним быстрый доступ.
Во, нечто вроде этого:
public class Model{

public static var car:Object = parseXML();

}
public class Car{

public var HP:int;
public var coordinates:Vector3D;

public var modelID:String = "12";

public function get modelName():String{

return Model.car[modelID].modelname;
}
public function get color():uint{

return Model.car[modelID].color;
}
}
В Model.car заносятся спарсенные данные машин из XML. Получается нечто вроде реляционной БД. Ну а экземпляру машины присваивается ID, что и является ее типом. Можно из Model достать соответствующие этому типу данные.

[ChuwY]

Вам просто нужно завести сущность более высокого порядка.
CarModel будет моделью конкретного экземпляра автомобиля.
А CarTypeModel будет моделью типа машины. Камаз, Лада, Мерседес.
И у них будут свои поля. Местами названиями совпадающие быть может и с моделью автомобиля.
Например имя. Имя типа -- камаз (грузовая машина), имя машины этого типа -- ржавый пень номер два.
Парсим данные по типу к модель типа, а потом в какой-нибудь фабрике собираем экземпляры машин по известным моделям типов (которые пришли с сервера). Также модель автомобиля может хранить ссылку на свой тип, как раз, например, для того, чтобы иметь знание о своей базовой скорости. (реальная скорость будет вычисляться на основании базовой и модофикаторов).

[Wolsh]

Модель хранит вектор (или Dictionary по айдишникам) экземпляров CarModel, представляющих реальные автомобили на трассе.
Эти экземпляры Модель создала фабрикой на основе полученного XML. Они хранят всю информацию о конкретных машинах.
(XML, между прочим, может содержать не только описания конкретных машин, но и абстрактных типов — вовсе необязательно хранить общие типы в хардкоде.
То есть в XML может быть описание уровня "Камаз" — общие для всех камазов характеристики, и конкретные машины типа "Камаз" с описанием только конкретных модификаций и свойств, как например цвет и имя водителя.)
Вьюха, получив от Модели этот список, создает на его основе экземпляры CarView — конкретные визуальные машинки на дисплее.
Экземпляры CarView могут хранить не всю информацию о машине, могут не хранить вообще никакой информации, только айдишник, но тогда на каждый шорох придется дергать Модель.
Если машин не тысячи, то лучше пожертвовать памятью чем быстродействием, и хранить в экземплярах CarView те данные, которые нужны на уровне Вью для ее расчетов отображения на каждом кадре (! если они не меняют Модель).
Есть такие данные, которые не нужны на каждом кадре, например цвет. После того как конкретная машинка нарисована, данные о ее цвете не нужны в процессе гонок.
Если же понадобится создать еще одну вьюху этой машины для диалогового окна гаража и модификаций, то цвет и все остальное будет снова взят из модели, это не повлияет на быстродействие.