Создаю стратегию.

[pu4koff]

Сообщение от Beermonza

Данные менять можно везде, а вот что можно изменить взаимотношения между классами, хоп предка вниз, потомка наверх, короче изменить дерево я честно сказать не знал.

Ну в делфях/С++/... нельзя, а в отдельных языках можно и для отдельного объекта (не класса, а именно объекта) добавить методы и свойства во время исполнения
Ну да я собственно этого и не предлагал

Сообщение от Beermonza

Ну, если взять игры, где берется тип корпуса, тип башни, и навешиваются оружия, то ни о каких классах "T-90" со стандартами внутри в коде речи быть не может.

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

Сообщение от Beermonza

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

В сущности на классах будет то же самое, только вместо вашего (я по крайней мере думаю, что примерно так у Вас):

нарисовать(текстуры[танк.ТипЮнита]);

1. всюду обращение к глобальной переменной
2. изменение способа хранения текстур повлечет за собой изменения по всему коду

будет такое:

танк.текстура.нарисовать;

совершенно пофиг чего там и как хранится и никакие глобальные переменные не нужны.

Сообщение от Beermonza

По сути выходит универсальный движок.

И сильно универсальный? прям вот можно n оружия на танк поставить, сделать разные параметры для лобовой, боковой и задней брони юнита и чтобы он еще вдобавок летал, пел и матерился?
Наличие такой структуры как GUnit уже ограничивает универсальность до предусмотренной Вами. Причем тут уже: шаг влево, шаг вправо - расстрел.

Допустим, у нас на карте могут быть следующие объекты: ящик, человек, автомобиль, танк.
Для ящика у Вас много лишней информации: скорость передвижения, броня,...
Для автомобиля не хватает: радиус поворота
Упираемся в универсальность? Либо добавлять радиус поворота в GUnit, но тогда для ящика еще больше лишнего станет и все файлики конфигурации править придется, т.к. новое свойство появилось.

Я же предлагаю:

ТОбъект = класс
  позиция
  текстура
...
конец;

ТДвигающийсяОбъект = класс (ТОбъект)
  скорость
...
конец;

ТЮнит = класс (ТДвигающийсяОбъект)
  броня
  оружие
  здоровье
  скорость
...
конец;

ТТехника = класс (ТЮнит)
  радиус поворота
...
конец;

Иерархия такого уровня врядли изменится. Ну разве что танки летать начнут, а этого не учли.

Так вот... впоследствии смотрим файл конфигурации наш и видим, что дальше идёт бочка. Соответственно создаём её как объект ТОбъект. Человек соответственно будет ТЮнит, а автомобиль и танк - ТТехника.
Ничего лишнего нигде не хранится. Всё только нужное Ну и виртуальные функции спасут от кучи if/else (алгоритм поиска кратчайшего пути и ИИ в скрипты всёже не засунешь наверно)
А самое замечательное - никакого дублирования кода и в случае чего расширяются возможности на ура: нового наследника создали и лепи себе новых юнитов на здоровье (при этом старых не нужно менять и соответственно заново тестировать)
ЗЫ. Лучше потратить больше времени на проектирование, чем на последующие тестирование и поиск багов

[Beermonza]

Год работает, можно сделать ресурсы танка, прицепить на самолет, и обратно, танк будет летать, самолет ползать по земле, никакого дублирования, у меня с этим жестко ))) ...а вот автор топа копировал на права и налево. Время нас рассудит.
На счет формул, то там все изменяется. Я в код не лезу практически, только меняю характеристики сейчас, ...ну и улучшаю по мере надобности, когда все предусмотрю в компакте, то будет 2D движок с внешним управлением. Вот еще сеть - долгая песня, так что все силы брошены туда.

[pu4koff]

Сообщение от Beermonza

Год работает, можно сделать ресурсы танка, прицепить на самолет, и обратно, танк будет летать, самолет ползать по земле, никакого дублирования, у меня с этим жестко ))) ...а вот автор топа копировал на права и налево. Время нас рассудит.

Ну это пока Вы активно разработку ведёте и всё помните что где и как делается. На полгодика если забросить работу над двигом и решить потом пару формул изменить, то ситуация, думаю, несколько изменится. Разве что документация не на каждой строчке
Еще одним преимуществом активного использования ООП - можно жестко задать, какие данные можно изменять, а какие только на чтение.
Ваш же подход требует от программиста внимательности. Чтобы не:

танк.позицияХ := 10;
танк.позицияY := 20;

писал, а обязательно:

переместить(танк, 10, 20);

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

[Beermonza]

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

UnitsMas[i].GTPosX := 10;
UnitsMas[i].GTPosY := 10;
UnitsMas[i].GTPointX := 40;
UnitsMas[i].GTPointY := 40;

все! ...юнит поехал, ничего больше не нужно, плюс синхронизация, где он был, ..это очень удобно в ММО.

[pu4koff]

Сообщение от Beermonza

Ну мы люди грамотные, и понимаем, что комп не может думать, он просто перебирает данные ))), да и "инакомыслить" ему процедуры не дадут.

Дадут. Данные совершенно никак не защищены. Можно написать:

UnitsMas[i].GTPosX := -100;

и где эта ошибка потом в итоге всплывёт не известно. В классе же запрятали всё по свойствам и get/set методам и выдаём себе исключение, если неположенное значение записываем или еще как поступаем.

Сообщение от Beermonza

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

Мне классы понятнее. Вижу класс Танк и понимаю, что в нём всё про танк написано. Вижу метод "ехать" и понимаю что при вызоке его танк поедет и всё в этом духе. При Вашем подходе танк отдельно, операции, производимые над ними отдельно и всё это размазано по разным модулям.

Сообщение от Beermonza

Я как-то отставлял проект, вернувшись ничего не забыл, все логично до безобразия, и переменные названы по правилам.

Помните, что если состояние танка = 0, значит он стоит, а если 5 - значит едет, а при 666 - подбит? Или то, что после изменения позиции танка, нужно обязательно вызвать вот эту функцию вот с этим параметром, а то будет плохо? Хотя может у Вас код так хорошо организован и прокомментирован, так что спорить не буду

Сообщение от Beermonza

В любой момент я посылаю пакет:

UnitsMas[i].GTPosX := 10;
UnitsMas[i].GTPosY := 10;
UnitsMas[i].GTPointX := 40;
UnitsMas[i].GTPointY := 40;

все! ...юнит поехал, ничего больше не нужно

В один прекрасный момент забыли послать пакет, а значения изменили. Что будет?
На классах я напишу: танк.езжай_сюда(х, у); и больше не надо ничего никуда слать, всё, что надо, где-то в недрах класса "само" произойдет.

Сообщение от Beermonza

это очень удобно в ММО.

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

[Вадим Буренков]

Спор бесполезен, ведь каждый считает что его метод вернее. И вообще какая разница?Главное чтоб программисту было удобно работать и получившийся продукт был играбелен.

Главное не переходить от спора к флуду.

[JTG]

Вот-вот, не начинайте холивар, оба подхода имеют право на жизнь, вон вся OpenGL на процедурах, и тем не менее. Я ушёл писать статью об ООП в играх на примере ремейка BattleCity, может к понедельнику успею

[Beermonza]

Да не разводим мы тут ничего, просто пробуем определить новичка в каком направлении работать, наше дело рассказать где как, а ему выбрать.
pu4koff, не будем трогать сеть пока, извиняюсь за "заброс удочки" в ту сторону, ...тип Byte сам по себе не принимает никаких значений кроме 0-255, это у меня часто возникало в процессе построения алгоритмов в режиме теста, сверхъестественного ничего не происходит, просто не нужно в ресурсах указывать тип состояния 666, даже если вы это напишете, то редактор ресурсов вам не даст записать такое значение, а так если мыслить, то все мы встречались с глючными картами "Heroes of Might and Migic", "WarCraft", "StarCraft" и пр. пр. пр.
"Забыть послать пакет, а значения изменить" в принципе не возможно, значения меняются только по пришествию пакета, ...стоп стоп, ...извиняюсь опять сеть ))) ...в крайнем случае, все данные меняются не в ручную а по процедурам, с родни классам и записи Tank.поехал(X,Y) у меня Перемещается(объект,X1,Y1,X2,Y2), а вот как перемещается, зависит от ресурсов, ...я же не буду писать классы: едет, летит, ползет.

[Shadow_1329]

А что насчет перемещения?

[Beermonza]

Почти сделал пример, сегодня еще есть время, постараюсь выложить.