Мастерская: Основные аспекты программирования игр

[Beermonza]

Killbrum, я в свое время пораскинул мозгами и придумал такую запись:

Var
  Dir: String;
...
procedure TForm1.FormCreate(Sender: TObject);
begin
  Dir:=GetCurrentDir;
...
end;

...

Buf.LoadFromFile(Dir+'\ResourceBMP\Start.bmp');
// при условии что каталог ResourceBMP у вас в каталоге проекта
...

Таких Dir'ов можно наделать при создании формы уже с полным путем, только подставить в последствии имя самого файла.

[Longedok]

Вопрос к Kostе. В посте номер 12, вы говорили про синусоиду обвивающую окружность. Стало интересно. Не могли бы вы описать решение этой задачи.

[DeKot]

Продолжим рассмотрение принципов построения Игры.
Следующий этап - сохранение и загрузка сохраненной игры.
Перед тем , как рассмотрим блок-схему загрузки программы (которую предварительно сохранили), рассмотрим процедуры сохранения Игры и загрузки.
Что нам нужно сохранить в памяти, чтобы потом вывести Игру в полном формате?
Во – первых, конечно уровень , а точнее индексы блоков, составляющих запоминаемый уровень.
Далее – № склада, положение Грузчика (координаты), кол-во шагов, кол-во ключей, “уровень жизни”, еще понадобится флаг (признак) наличия ключей и еще индексы сегментов карт.
Хранить будем в текстовых файлах - mem_index.txt – индексы и mem_data.txt - остальные
данные.
После запуска Игры с любого места при нажатии кнопки меню “Сохранить” вызывается процедура LoadGame и далее WriteIndex и WriteData.
Обе эти процедуры не очень сложные, используют стандартные операторы Pascal. Первая
записивает индексы всех уровней в массивы. Вторая - данные текущего уровня и массив
индексов сегментов карт.
Теперь процедуры чтения : ReadIndex и ReadData.
Если мы запустим режим “Загрузить” из меню, но при этом Игра не была сохранена, т.е.
файлы памяти mem_index и mem_data отсутствуют, то OS Windows будет ‘ругаться’, Игра
прервется. Поэтому используем директиву отключения автоматической проверки ошибок -
{$I-} и переведем эту проверку на Delphi.
Перед попыткой открытия файла памяти - {$I-} Reset(file) и возврат к автоматической
проверке системой Windows – {$I+}.
После проверки Delphi возвращает значение переменной IOResult . Если файл существует,
IOResult = 0, в противном случае код ошибки, отличный от нуля. И если IOResult = 0 , то
происходит считывание данных из файла, в противном случае выводится сообщение о том,
что Игра не сохранена и следует начать Игру сначала. Используем здесь флаг чтения –
flag_read, как признак успешного открытия файла памяти ( =0 - все ОК)

Смотрим блок-схему 3 режима загрузки файла (это касается как кнопки загрузить из Form 1
(модально через Form 5), так и аналогичной кнопки меню Form 4 :

После команды «Загрузить» мы переходим в блок-схему 2 : если Игра еще не была
сохранена (файлы Index или Data отсутствуют) - переход к NewGame с исходными параметрами переменных или же при сохраненной Игре переход к GameSklad c сохраненными
параметрами переменных. И опять после прохождения программы по блок-схеме 2 программа
оказывается в procedure TForm4.FormKeyDown(Sender: TObject; var Key: Word; Shift: TShiftState);

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

   ((1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1), // S1
    (1, 1, 2, 2, 2, 2, 1, 1, 1, 1, 1, 2, 2, 5, 1),
    (1, 1, 2, 2, 3, 2, 3, 2, 1, 1, 1, 5, 5, 5, 1),
    (1, 1, 2, 1, 2, 2, 3, 2, 1, 1, 1, 2, 2, 5, 1),
    (1, 1, 2, 2, 3, 3, 3, 2, 2, 2, 3, 2, 2, 5, 1),
    (1, 1, 1, 1, 2, 2, 3, 2, 2, 3, 1, 2, 2, 5, 1),
    (1, 1, 1, 1, 2, 2, 3, 1, 3, 2, 1, 5, 5, 5, 1),
    (1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 1, 2, 2, 5, 1),
    (1, 1, 1, 1, 1, 7, 1, 1, 2, 1, 1, 1, 1, 1, 1),
    (1, 1, 2, 2, 2, 2, 1, 1, 2, 2, 1, 2, 2, 2, 1),
    (2, 2, 3, 2, 3, 3, 2, 1, 2, 3, 5, 5, 3, 2, 1),
    (1, 5, 5, 5, 5, 5, 5, 2, 2, 3, 5, 4, 2, 1, 1),
    (1, 2, 3, 3, 2, 3, 2, 1, 2, 3, 5, 5, 3, 2, 1),
    (1, 1, 1, 2, 2, 1, 1, 1, 2, 2, 1, 2, 2, 2, 1),
    (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1)),

Это первая запись которая мне непонятна. Я так понял что это и есть уровень, но что тут написано не пойму, можете объяснить?

[Kostia]

2Longedok

procedure SinRound;
var
  a,b: real;//a - для окружности, b для волнистой окружности.
begin
  a:=0; b:=0;
  while a<=pi*2 do
    with form1.Canvas do
    begin
      Pixels[round(cos(a)*(50+sin(b)*5))+100,round(sin(a)*(50+sin(b)*5))+100]:=0;
      Pixels[round(cos(a)*50+100),round(sin(a)*50+100)]:=0;
      a:=a+0.01;
      b:=b+0.1;
    end;
end;

Синус и косинус изменяются от -1 до 1 и если менять радиус окружности на sin или cos, то она получится волнистой. Но изменение на 1 пиксел это слишком мало и поэтому я sin домнажаю на 5.

[mutabor]

Сообщение от Манжосов Денис :)

   ((1, 1, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1), // S1
    (1, 1, 2, 2, 2, 2, 1, 1, 1, 1, 1, 2, 2, 5, 1),
    (1, 1, 2, 2, 3, 2, 3, 2, 1, 1, 1, 5, 5, 5, 1),
    (1, 1, 2, 1, 2, 2, 3, 2, 1, 1, 1, 2, 2, 5, 1),
    (1, 1, 2, 2, 3, 3, 3, 2, 2, 2, 3, 2, 2, 5, 1),
    (1, 1, 1, 1, 2, 2, 3, 2, 2, 3, 1, 2, 2, 5, 1),
    (1, 1, 1, 1, 2, 2, 3, 1, 3, 2, 1, 5, 5, 5, 1),
    (1, 1, 1, 1, 1, 2, 2, 2, 2, 2, 1, 2, 2, 5, 1),
    (1, 1, 1, 1, 1, 7, 1, 1, 2, 1, 1, 1, 1, 1, 1),
    (1, 1, 2, 2, 2, 2, 1, 1, 2, 2, 1, 2, 2, 2, 1),
    (2, 2, 3, 2, 3, 3, 2, 1, 2, 3, 5, 5, 3, 2, 1),
    (1, 5, 5, 5, 5, 5, 5, 2, 2, 3, 5, 4, 2, 1, 1),
    (1, 2, 3, 3, 2, 3, 2, 1, 2, 3, 5, 5, 3, 2, 1),
    (1, 1, 1, 2, 2, 1, 1, 1, 2, 2, 1, 2, 2, 2, 1),
    (1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1)),

Это первая запись которая мне непонятна. Я так понял что это и есть уровень, но что тут написано не пойму, можете объяснить?

Это матрица (двумерный массив) 15х15, нехватает объявления только, ты его где-то потерял. Тип byte для этой конкретной матрицы подходит лучше всего. Матрица заполнена сразу при объявлении, эти цифры это и есть ее содержимое.
Внешние скобки открывают первое измерение массива, затем в скобках через запятую перечислены вложенные одномерные массивы - второе измерение.
Я тоже думаю, что это уровень, цифрами закодированы клетки уровня, например 1 - пусто, 2 - стена, ну и дальше в таком роде, что именно значат цифры автор кажется уже писал.

[Iceman]

аа опоздал . Мой вариант с синусом.

[DeKot]

Для Дениса :
В разделе type объявлен новый тип данных :
TIndex = array [0..14,0..14] of integer; - это двухмерный массив. Далее const - all_mas : array [0..5] of TIndex = ...
Объявлена константа - одномерный массив двухмерных массивов и
сразу же всем элементам присвоены значения.
S1 .. S6 - это элементы массива all_mas. Cодержат информацию об
уровнях в виде двухмерной матрици ( то же что и массив) индексов каждого сегмента уровня ( 15 х 15). Индекс - это и есть
тип блока склада( или уровня). 1 - это стена (Kirp) 2 - пустое место
(Pust) 3 - сундук (Sund) и т.д.
Т.о. S1 - это данные для построения 1-го склада, S2 - для 2-го и т.д.

[DeKot]

Eще нюанс. Значения массивов укладываются в тип byte, однако присвоен тип integer. Дело в том, что в дальнейшем мы вычисляем значения элементов массивов по координатам X и Y , имеющим тип
integer. Поэтому типы данных координат и элементов массивов должны совпадать.

[mutabor]

Хочу оставить пару комментариев.

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

const - all_mas : array [0..5] of TIndex - это уже трехмерный получается (одномерный массив двумерных). Четырехмерный = одномерный массив трехмерных и т.д.
Не обратил внимания, в том куске к-рый Денис вырезал, матрица заканчивается запятой, точно трехмерный.
Также можно было его так объявить
all_mas : array [0..5] of array[0..14] of array[0..14] of <тип данных>

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

P.S.

Дело в том, что в дальнейшем мы вычисляем значения элементов массивов по координатам X и Y , имеющим тип
integer. Поэтому типы данных координат и элементов массивов должны совпадать.

Здесь это допустимо, но в более "тяжелых" играх ради экономии памяти это легко обойти и использовать в массивах тот тип к-рый более экономный.
Кстати если интегер умещается в предел байт, можно смело присваивать, если не умещается тоже теоретически можно, но будет переполнение, т.е. на практике ерунда получится (если конечно так не было задумано).