История изменений

Может для загрузки так и оптимально, но для выполнения каждый раз при обращении к объекту разбирать XML это как то не оптимально.

Нет, ты не в курсе. Разбор выполняется один раз на абстрактном уровне. В классы-обработчики передаётся (для модели DOM) поддерево объектов в памяти. И даже если нужно всё это распихать по более удобным (по какой-то причине) структурам, это можно сделать один сразу после parse.

А насчёт неконтролируемости формата, его контроль осуществляет обработчик нужного ID.

Очень ограниченный контроль, как я и пытался показать выше.

И наверно уже повторюсь, использование GameObjectDataClass нужно только если для описания свойства не подходит строковая или численная переменная.

То есть для любого составного типа. А таких у тебя будет много, если доведёшь проект до рабочего состояния.

Чувствую, я тебя не убедил. Что ж, делай как знаешь, но всё же рекомендую подучить XML-технологии, DOM, XSD. Я считаю, что там всё нужное есть. Даже если сейчас ты не будешь ими пользоваться - пригодится в следующем.

И ещё: избегай в программе комментариев в стиле Капитана Очевидность: «очистка массива», «обнуление переменной ссылки» и др. В приведённом примере таких комментариев, увы, больше половины. Комментарии пишутся не для неуча, который не знает язык программирования, а для программиста, которому нужно вспомнить, ДЛЯ ЧЕГО написан тот или иной оператор. К примеру, при обнулении можно напомнить, массив ЧЕГО ты обнуляешь.

Вообще, если код написан хорошо, комментировать каждую строку не нужно. Достаточно сделать шапку для модуля, комментарий для класса, комментарий в начале каждой функции/метода и комментарии для НЕОЧЕВИДНЫХ фрагментов кода. Если функция большая (чего, как правило, следует избегать) - комментарии к разным частям алгоритма. Когда комментариев больше кода, код теряется.

В сам код, прости, я сильно не вникал: там ещё много чего, вероятно, можно было бы написать, но этим пусть занимаются гуру бейсика, коих на ЛОРе, боюсь, не очень много. И русский язык всё же подучи: формулировки типа «здесь надо будет сохранено куча строк» глаз режут.

Удачи.

Может для загрузки так и оптимально, но для выполнения каждый раз при обращении к объекту разбирать XML это как то не оптимально.

Нет, ты не в курсе. Разбор выполняется один раз на абстрактном уровне. В классы-обработчики передаётся (для модели DOM) поддерево объектов в памяти. И даже если нужно всё это распихать по более удобным (по какой-то причине) структурам, это можно сделать один сразу после parse.

А насчёт неконтролируемости формата, его контроль осуществляет обработчик нужного ID.

Очень ограниченный контроль, как я и пытался показать выше.

И наверно уже повторюсь, использование GameObjectDataClass нужно только если для описания свойства не подходит строковая или численная переменная.

То есть для любого составного типа. А таких у тебя будет много, если доведёшь проект до рабочего состояния.

Чувствую, я тебя не убедил. Что ж, делай как знаешь, но всё же рекомендую подучить XML-технологии, DOM, XSD. Я считаю, что там всё нужное есть. Даже если сейчас ты не будешь ими пользоваться - пригодится в следующем.

И ещё: избегай в программе комментариев в стиле Капитана Очевидность: «очистка массива», «обнуление переменной ссылки» и др. В приведённом примере таких комментариев, увы, больше половины. Комментарии пишутся не для неуча, который не знает язык программирования, а для программиста, которому нужно вспомнить, ДЛЯ ЧЕГО написан тот или иной оператор. К примеру, при обнулении можно напомнить, массив ЧЕГО ты обнуляешь. Вообще, если код написан хорошо, комментировать каждую строку не нужно.

В сам код, прости, я сильно не вникал: там ещё много чего, вероятно, можно было бы написать, но этим пусть занимаются гуру бейсика, коих на ЛОРе, боюсь, не очень много. И русский язык всё же подучи: формулировки типа «здесь надо будет сохранено куча строк» глаз режут.

Удачи.