История изменений
Исправление hobbit, (текущая версия) :
А игровому серверу без разницы как юнит выглядет в 2D редакторе, он просто при событии будет последовательно передавать все элементы из нужных диапазонов в классы обработчики.
А если бы у тебя был xml, то сервер точно так же передал бы в класс-обработчик ссылку на DOM-объект, соответствующий тегу <unit>, вместе со всеми дочерними объектами - не вникая в их суть, как ты и хотел. При этом разбор файла вместе с синтаксическим контролем выполняется одной строкой программы. Википедия подсказывает, что XML-парсер в Гамбасе есть (я правда, не знаю, что он поддерживает - DOM, SAX или обе модели).
Допустим броня описывается комбинацией цифр, таких как толщина, плотность, вязкость, керамический коэффициент комбинированной брони и угол наклона в 3х проекциях. Значит это массив цифр.
Судя по первой фразе - как раз не массив, а структура (запись). Применительно к XML - набор разноимённых (что принципиально) атрибутов внутри тега <armor>. Применительно к INI - набор разноимённых переменных внутри секции. А у тебя да, получается массив никак не контролируемого формата.
комбинированной брони
Несколько секунд думал, при чём тут пони. ЛОР действует на мышление :)
Но если всё же приспичит, то я введу проверку размеров массивов в обработчике (в коде нового функционала). И если элементов меньше чем надо, то новый функционал не обрабатывать или возвращать затычки.
Количество ты так проконтролируешь, состав - нет. А если один параметр добавился, а другой (устаревший) выкинут? Нет, ну можно старые оставлять для совместимости? Далее, при твоём подходе новые элементы можно добавлять только в конец, даже если их группировка подсказывает обратное.
P.S. Честно говоря, если б я начинал новый проект и хотел его написать не на C или C++, я бы выбрал FreePascal. Хороший язык, пронизан структурным подходом, строгая типизация (в отличие от всех известных бейсиков). Но это дело вкуса...
Исходная версия hobbit, :
А игровому серверу без разницы как юнит выглядет в 2D редакторе, он просто при событии будет последовательно передавать все элементы из нужных диапазонов в классы обработчики.
А если бы у тебя был xml, то сервер точно так же передал бы в класс-обработчик ссылку на DOM-объект, соответствующий тегу <unit>, вместе со всеми дочерними объектами - не вникая в их суть, как ты и хотел. При этом разбор файла вместе с синтаксическим контролем выполняется одной строкой программы. Википедия подсказывает, что XML-парсер в Гамбасе есть (я правда, не знаю, что он поддерживает - DOM, SAX или обе модели).
Допустим броня описывается комбинацией цифр, таких как толщина, плотность, вязкость, керамический коэффициент комбинированной брони и угол наклона в 3х проекциях. Значит это массив цифр.
Не цифр, а чисел. И (по первой фразе) как раз не массив, а структура (запись). Применительно к XML - набор разноимённых (что принципиально) атрибутов внутри тега <armor>. Применительно к INI - набор разноимённых переменных внутри секции. А у тебя да, получается массив никак не контролируемого формата.
комбинированной брони
Несколько секунд думал, при чём тут пони. ЛОР действует на мышление :)
Но если всё же приспичит, то я введу проверку размеров массивов в обработчике (в коде нового функционала). И если элементов меньше чем надо, то новый функционал не обрабатывать или возвращать затычки.
Количество ты так проконтролируешь, состав - нет. А если один параметр добавился, а другой (устаревший) выкинут? Нет, ну можно старые оставлять для совместимости? Далее, при твоём подходе новые элементы можно добавлять только в конец, даже если их группировка подсказывает обратное.
P.S. Честно говоря, если б я начинал новый проект и хотел его написать не на C или C++, я бы выбрал FreePascal. Хороший язык, пронизан структурным подходом, строгая типизация (в отличие от всех известных бейсиков). Но это дело вкуса...