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

[Shadow_1329]

А исходники смотрели?

[Beermonza]

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

type
  RusTanks = packed record
    Ux:integer;
    Uy:integer;
    UWidth:integer;
    Uheight:integer;
    Utexture:Tbitmap;
    Selected:boolean;
    Up,Down,Left,Right:boolean;
    UBorn:boolean;
  end;

type
  GermTanks = packed record
    Ux:integer;
    Uy:integer;
    UWidth:integer;
    Uheight:integer;
    Utexture:Tbitmap;
    Up,Down,Left,Right:boolean;
    UBorn:boolean;
  end;

А?

[Shadow_1329]

Дело в том что я еще буду дописывать свойства в GermTanks отличные от RusTanks(вроде перемещения и т.д.).

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

Тогда пользуйся наследованием:

type
  Tank = class
    Ux:integer;
    Uy:integer;
    UWidth:integer;
    Uheight:integer;
    Utexture:Tbitmap;
    Selected:boolean;
    Up,Down,Left,Right:boolean;
    UBorn:boolean;
  end;

  RusTank = class (Tank)
//доп-ные параметры 
end;

  GermTank = class (Tank)
//доп-ные параметры 
end;

[Shadow_1329]

Ок. Я это учту на будущее! Но блин проблема не в этом!

[Beermonza]

У меня есть немного времени в неделю, помогу советами и кодом.
Вообще мыслите изначально не верно. Никаких наследований не нужно. Суть, у нас есть тип игрового юнита, ОН (тип) ОДИН! ...все юниты могут передвигаться, атаковать, погибать, появляться и пр. ...зачем нужно кучу одинаковых записей и еще потом выбирать по двум спискам где какой юнит, твой или вражеский? Список должен быть один, пробежался по списку и обновил данные у всех юнитов по одному и тому же набору записей.
Немного подумайте, что для определения свой/чужой нужна только одна переменная в типе, если это переменная Byte, то у вас может быть 256 рас в игре, достаточно считывать эту переменную.
Второе, даже здания могут быть в том же типе юнита, только есть переменная отвечающая за тип юнита. С помощью двух переменных в одном и том же типе: "Свой/чужой" и "Тип Юнита" можно управлять всеми объектами в игре, это как личные номера, по этим номерам выдается изображение (анимация) и все личные параметры типа юнита. Структура древовидная.
Вот пример общего типа:

// тип игрового объекта GUnit (G - game, Unit - юнит)
type
  GUnit = packed record
    GTUnitType: Byte;       // тип юнита
    GTType:      Byte;      // раса (1 - RUS, 2 - GER, 3 - USA)
    GTStatus:    Byte;      // состояние (0 - стоит, 1 - едет, 2 - стреляет, 4 - погибает)
    GTUses:      Boolean;   // использование танка (в игре/не в игре)
    GTSelected:  Boolean;   // выделение танка

    GTPosX:      Word;      // позиция по-X
    GTPosY:      Word;      // позиция по-Y
    GTPointX:    Word;      // конечная позиция по-X
    GTPointY:    Word;      // конечная позиция по-Y
    GTMoveX:     ShortInt;  // смещение по карте на пиксел по-X
    GTMoveY:     ShortInt;  // смещение по карте на пиксел по-Y

    GTWidth:     Word;      // длина текстуры танка
    GTHeight:    Word;      // ширина текстуры танка
    GTDispX:     ShortInt;  // смещение статичное по-X
    GTDispY:     ShortInt;  // смещение статичное по-Y

    GTAnimType:  Byte;      // тип анимации (движение, стрельба, гибель)
    GTKadr:      Byte;      // текущий кадр
    GTMaxKadr:   Byte;      // максимальное число кадров
    GTRound:     Word;      // поворот на угол

    GTSpeed:     Real;      // скорость танка
    GTArmor:     Byte;      // броня
    GTWeapon:    Byte;      // сила пушки
    GTHPMax:     Word;      // количество жизней
    GTHP:        Word;      // текущее количество жизней
  end;
// --------------------------------------------------

[JTG]

все юниты могут передвигаться, атаковать, погибать, появляться и пр.

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

а проверка столкновений сводится к

if objectAt[x,y] is TEnemyTank then (map[x,y] as TEnemyTank).Dead , Bullet.Dead
if objectAt[x,y] is TStrongWall then Bullet.Dead
if objectAt[x,y] is TWeakWall then (map[x,y] as TWeakWall).Dead , Bullet.Dead
...

в методе onCollide снаряда, псевдокод конечно.

Такой подход очень удобен, юнит несёт в себе всю необходимую информацию и способы взаимодействия. Кроме того не нужно рисовать всех во внешней процедуре: есть только одна "синхронизирующая" DoDraw которая зацикленно вызывает TXxxxx.Draw для всех объектов, сказал юниту TTank.Dead и забыл - он сам займется уничтожением себя и рисованием на карте лужи крови

ЗЫ: Щас пишу стрелялку аля crimsonland под Asphyre, тока тссс-ссс

[Beermonza]

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

[Shadow_1329]

Ооо! Спасибо! Я сейчас делаю две стратегии и мне во второй это очень помогло. Но мне нужно доделать первую(танки), и в ней мне только осталось сделать столкновения и непроходимость сквозь препятствия(это я понять просто в упор не могу, так как что-то не так обрабатывается), а остальное там все понятно. А вот во второй у меня там будут и ресурсы,и строительство, и сельское хозяйство, и найм юнитов в общем одна огромная карта. Со второй вы мне реально помогли. У меня вместо бесконечных записей теперь будет компактный код.

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

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

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

По поводу использования классов или одного типа, то это дело программиста. Мне больше нравится использование классов, но каждому свое.