Моя первая игра CosmoNoid (canvas)

[Манжосов Денис :)]

Вот еще одна версия с 5 оружиями. Переключение клавишами 1-5(после того как выбрал оружие нужно подождать когда оно перезарядится).
Есть одна проблема с ракетой, она вырисовывается с белым фоном(скорее всего из за изображения).Ты можешь исправить?
Вложения Many Enemies + 5 weapons.rar (500.2 Кбайт, 2 просмотров)

А тут баг есть. При смене оружия враги не поражаются оружием.

[Beermonza]

Вадим Буренков, смотрим твой код:

TEnemy = class {класс врага}         //OK
   Enemy: Tbitmap;  //изображение врага
   Boom: Tbitmap; // анимация взрыва
   Xpos,Ypos:integer;//позиция врага
   Xspeed, Yspeed:integer;//скорость врага
   EnemyBorn : boolean;//появился ли враг?
   Procedure LoadMem;
   Procedure FreeMem;
   Procedure CreateEnemy;
   procedure DestroyEnemy;
   procedure DrawEnemy;
end;

Сравнение процедур классов для "разных" типов объектов:

Procedure LoadMem = Procedure LoadBot = Procedure LoadTree
Procedure FreeMem = Procedure FreeBot = Procedure FreeTree
Procedure CreateEnemy = Procedure CreatePers = Procedure CreateTree
procedure DestroyEnemy = Procedure DestroyPers = Procedure DestroyTree
procedure DrawEnemy = procedure DrawBot = procedure DrawPers = procedure DrawTree

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

Сразу следует думать вперед шагов на десять. Предполагая большое множество объектов, задать им такой тип, чтобы было легко работать как с персонажами, движущимися объектами, так и со статичными, тогда проблемы со стыковкой и лишней писаниной вам не грозят. Достаточно поменять параметры в файле для конкретного объекта, в игре он отобразиться и будет действовать по написанному шаблону, используя общий фундаментальный алгоритм изменения своего состояния.

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

А тут баг есть. При смене оружия враги не поражаются оружием.

Багов нет! Просто еще не сделано ни одной версии с коллизией (кроме самой первой где было 3 врага и стреляло по одному патрону). Ей я сейчас занимаюсь.А эту версию я выложил чтобы показать баг с ракетой (уже исправлен).

Вадим Буренков, смотрим твой код.............класса по одной процедуре?

Я ничегоооо не понял.....

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

У меня реализовано 3 основных класса: TEnemy,TWeapon и TAmmo
Каждый из ниж отвечает за свое. Мне это не мешает. Зачем использовать какой-то один?Теперь я просто занимаюсь гибкостью классов.
Например в последней версии игры я изменил процедуру создания TEnemy.LoadMem; на TEnemy.LoadMem(Path:string);, где Path-путь для изображения врага.Это дает мне возможность для создания врагов различных видов.

[Beermonza]

Если все делать просто, то все классы TEnemy, TWeapon и TAmmo - суть, составные части одного. В нем: тип объекта, подтип объекта, флаги состояния, указатели на анимацию, очки жизни, брони, оружия, его тип, патроны и пр. пр. пр. Это все относится к одному юниту. Мы же не будем в отдельном массиве хранить оружие или патроны к нему, и указатель на массив в котором сам юнит - владелец этого? Допустим, у нас есть база данных с оружием, достаточно выдернуть из не нужное и записать в класс (будем так называть) юнита как: оружие есть, тип такой-то, радиус атаки такой-то, количество патронов тут же. Тогда в цикле перебирая очередной объект определяем его тип, понятно как с ним работать, тут же все записи не "отходя от кассы", применяем общие процедуры и функции. Лично я уже намучился с гибкостью, просто режу все на корню, стереотипы "правильного программинга" через гибкие классы - утопия. Во всем нужно искать рациональность.

[mutabor]

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

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

К примеру у нас есть базовый класс TEnemy, у всех врагов есть такие свойства, как жизнь, сила и т.д. общие для всех врагов. И есть класс наследник - TGoblin, в нем свойства и методы общие с предком, повторно описывать нет нужды, а только его отличительные свойства, например уровень вони =) От TGoblin можно унаследовать класс TCrazyGoblin к-рый может отличаться всего лишь одни свойством CrazyLevel. Таким образом получаем иерархию классов. Польза от всего этого начинает ощущаться в больших, сложных проектах, в остальных случаях большой разницы как делать нет. Пользователю и подавно все равно, он когда давит на гашетку, не задумывается в кого он стреляет, в объект или в запись =)

Также бывает полезным другое свойство объектов - инкапсуляция, когда все эти массивы и методы их обработки находятся внутри класса и достаточно вызвать метод, а не перегружать код множеством строк с реализацией алгоритмов, а потом сам фиг разберешься в этих завалах. Но конечно же в любом случае, тут или там, в классе или в отдельных процедурах, но тот же самый код реализации написать придется, классы просто предоставляют больше удобства, на один уровень абстракции выше.

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

Beermonza, а ты не мог бы показать как лучше было бы составить код игры(можно схематично)

[Beermonza]

Сообщение от Вадим Буренков

Beermonza, а ты не мог бы показать как лучше было бы составить код игры(можно схематично)

Сложного ничего нет, нужно сесть и записать все параметры для объектов, которые могут понадобиться в игре, приблизительно прикинуть, потом расширять по мере поступления новых и нормализовывать, если появляется избыточность. Постепенно придешь к универсальному виду, где изменением нескольких записей можно "превращать" один объект в другой.
Допустим возьмем пример из стратегии. На первый взгляд какое сходство здания с воином? ...графически разное, вроде свойства разные, а модель почти одинаковая, нужна лишь пометка "здание" или "человек". У них у обоих есть тип, есть подтип. Это нужно для выдергивания из базы данных нужных параметров. У обоих есть индекс на анимацию, оба имеют координаты в пространстве, у обоих есть количество жизней. Тут можно сказать "а оружие?", вспоминается Империя 2, здание тоже может стрелять, тоже есть радиус обзора, атаки. А если не может, то параметр, отвечающий за наличие атаки, отрицательный.
Процедуры и функции. В итоге у нас есть один массив созданного нами универсального типа, в котором по мере появления на карте индексов объектов, или простой ввод юнитов в игру, обрабатывается каждый. Есть условие, если объект не здание, то применить процедуру ObjMove, если не человек - пропустить. Т.е. есть фильтр, просматривающий содержание указателей в типе объекта, и в зависимости от этого разрешает выполнить определенную процедуру, но опять же от состояния флагов в типе: переменные Boolean

двигается
действует
погибает
получает урон
появляется
исчезает

...их значения определяют, что с ними должен делать движок. Нужно описать универсальный объект набором таких "флагов". Понятно?
Так же есть флаг "используется", т.е. мы загрузили объект когда он был нужен, а как ушли с зоны где он располагался, просто помечаем, что объект не используется (UUses := False), цикл обработки просто пропустит этот объект. Как только объект снова нужен (вернулись назад по карте), индекс объекта на карте снова возвращает его в обработку.
Набор процедур:

двигаться
действовать
гибнуть
получать урон
появляться
исчезать

Как видно, те же самые, что и флаги. На вход требуют параметры позиционирования, радиуса обзора, наличия оружия, брони и пр. На выходе изменение состояния (запись во флаги новых состояний). "Получает урон" - процедура, требующая номер объекта в массиве, все флаги распределяться так: двигается = нет, действует = нет, погибает = нет, получает урон = да, появляется = нет, исчезает = нет. Собственно мы не трогаем флаги, кроме "получает урон".
Это то же самое что и в Quake: +forward, -forward, +moveleft, -moveleft, +attack, -attack, ...просто вкл/выкл. Это очень удобно.

Общая структура в словах. Есть база данных параметров всего, есть фильтр обработки этих параметров, есть один тип с набором записей, есть стандартный набор процедур и функций. Гибкость достигается усовершенствованием фильтра обработки параметров и добавлением новых флагов состояния в тип объекта.

Разумеется кроме объектов в игре есть иные типы, это интерфейс, шрифты, управление, ...они отдельные.

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

Но ведь не обязательно делать игры таким образом? Можно получить рабочий легко изменяемый код другим образом, например наследованием:

 TGameObject=class //класс игрового обьекта
   Image:Tbitmap//изображение
   Xpos,Ypos:integer;//позиция
   Xspeed, Yspeed:integer;//скорость

   Born:boolean;
   Procedure LoadMem; virtual 
   Procedure FreeMem; virtual
   Procedure CreateObj; virtual
   procedure DestroyObj; virtual
   Procedure Draw; virtual
end;

TStandartEnemy = class (TGameObject) // класс врага
Health:integer; //здоровье
Procedure AI; virtual //тип AI 1
end;

TAgressiveEnemy = class (TStandartEnemy) // класс врага
Procedure AI; virtual //тип AI 2
end;

TBoss = class (TStandartEnemy) // класс врага
Gun:TWeapon; //даем боссу оружие
Procedure AI; virtual //тип AI 3 умеющий стрелять
end;

......
TBonus = class (TGameObject);
.........
end;

...................

AI - поведение противника в игре.Таким образом можно создать монго моделей поведения.

Общая структура в словах. Есть база данных параметров всего, есть фильтр обработки этих параметров, есть один тип с набором записей, есть стандартный набор процедур и функций. Гибкость достигается усовершенствованием фильтра обработки параметров и добавлением новых флагов состояния в тип объекта.

В такую систему тоже можно засунуть "фильтр обработки"
Предлагаю завершить разговор по этой теме здесь.Лучше создать новую тему если надо.

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

Вот нашёл несколько анимаций,только они все по одному файлу.Ты смжешь использовать их?

Выкладываю новую версию и ресурсы к ней (ресурсы отдельно чтоб каждый раз не выкладывать)
Нововведения:
1)Появилась коллизия
2)3 типа врагов (3-ий вид часто глючит )
3)У врагов появились жизни а у оружия сила урона
4)Появился звук.
5)Лазер пробивает врагов насквозь
6)Иконка выбранного оружия на панеле.
7)Оптимизация движка.
8)Исправлено два бага.

[Beermonza]

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