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

[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/que...ipting-in-game