game making (c) demon/xpc/cpu

"видеоигры - это способ выражения самых фантастических идей и образов. многим просто необходима отдушина для воплощения своих безумных фантазий..."

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

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

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

первой из них является вопрос, какую игру я (мы) хочу делать, и что бы я хотел в ней увидеть, а чего нет. хочется-то много, но не многое зависит от уровня подготовленности разработчиков и возможностей машины. уже вряд ли кто превзойдет славу медноногова в создании стратегий или system 3 по красочности ее игры "myth" . в первую очередь определяем свои возможности и желания, после чего вырабатываем компромисс между ними.

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

не знаем с чего начать! здесь могу сказать только для кодеров. в первую очередь нужно создать библеотеку основных программ то бишь: выводилки спрайтов, печаталки текстов, опрашивалки клавы и мыши, лоадеры и записывалки, листалки памяти и т. д., т. е. то, что без сомнения будет нужно в нашей игре. на первом этапе мы уже должны были решить вопрос интерфейса с пользователем (занимает не менее 30% от общего времени создания программы) и теперь это будет одним из больных вопросов и для тебя. здесь должен быть особый подход, т. к. надо придерживаться уже устоявшихся определениий. ну например, будет хорошим тоном, если мы сделаем поддержку kempston mouse и переопределение управляющих клавиш (хотя бы поддержку sinclair и qaop+space ). и, конечно, неплохо добавить что-нибудь этакое, что мы и попыпались сделать в "full shit" . правда до последнего момента никто из нас не представлял, как все это будет работать и выглядеть... после того, как мы сделаем (или выберем уже готовые во многих электроных изданиях) процедурки, начинаем думать об основном: главном модуле программы, который для каждой игры будет своим. так как я делал квест, то для меня было главным вывод локации, предметов и героев на ней, и процесс управления героем. например, для какого-нибудь battle command это будет работа с 3d обьектами и всяческие отсекалки лучей, проекционные выводилки... рассмотрим все-таки на примере "full shit demo-version" , что и как я делал.

1) пока ant и vaniac (gfx-makers) рисовали графику, я клепал процедурки для игры (см. выше). после появления первого скрина, решил использовать оба экрана спека , т. к. скрин без 4-х верхних строк занимал 5120 байт. 4 верхние строки были сделаны статичными не случайно, а для синхронизации луча. после навеса всех примочек на прерывания, до игрового экрана осталось всего около 1000 тактов ( на скорпе ). после я жалел о том, что стал использовать не буфер а два экрана, но было уже поздно... быстро сделав прорисовку локации:

1. скрин по ldi, ldi, ldi... ldi 2. спрайты предметов сверху по маске 3. спрайт главного героя 4. спрайты других предметов по маске

2) я сделал убогое управление героем по клавам r, l, d, u. погоняв процедуру хождения (задается количество шагов и направление, а по таблице она сама выводит нужные спрайты хождения и делает смещение координат), решил заняться интерфейсом пользователя. забацал вывод стрелки почти без дергания бордера при ее движении (никаких декранченных спрайтов) и сделал опрос клавы и мыши, не имея возможности проверить энту самую мышь. проблема появилась, когда необходимо было переключать видимый экран. я ступил и переключал его не в прерываниях, а после halt'а. из-за чего возникали глюки порчи игрового экрана стрелкой и появления стрелки-призрака при движении оной. поэтому совет: - если работаешь с двумя экранами, и у тебя что-то выводится на экран в прерываниях, то переключай экран в самом начале прерываний, например:

 
;----------- interrupt mode 2
int_2
   push af,hl,de,bc,ix,iy
   exx
   ex af,af'
   push af,hl,bc,de
   call scr_swp;   переключаем экран(ниже)
   call sav_pag;   сохраняем номер текущей
;                  страницы памяти

   call det_scr; определяем видимый экран
   call cr_undo; восстанавливаем если тот
;                же, нет - если переключен
   call cr_save; запоминаем
    call cr_print;   рисуем стрелку
    ............
    call muzak
    call on_undo; включаем cr_undo
    call und_pag; восстанавливаем страницу
 ;                памяти
    pop de,bc,hl,af
    ............
    ei
   ret

 ;------------- screen swap
scr_swp
    ret;            выключатель (#c9 or 0)
    ld a,#c9
    ld (scr_swp+1),a
    ld (cr_undo),a; вырубаем cr_undo
 ;                  включим при выходе
 
 scr_sta
    ld a,0;         статус 0-#4000, другое
;                  для #с000
    or a
    ld а,(now_pag); текущая страница
    jr z,sw_l1
    set 3,a
    jr sw_l2
    res 3,a
 sw_l1
    ld (now_pag),a
    ret

 ;---------- on_undo
    xor a
   (cr_undo),a
    ret
 
 ;---------- undo under cursor
 cr_undo
    nop
    ........
    ret

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

a ща я хочу рассказать о непонимании между кодером и графмейкером. когда я сказал, чтоб мне нарисовали спрайты передвижения героя 10 на 4 (в знакоместах), мне принесли их аж на 14 килобайт, да еще разного размера. неподумав, я их взял и начал бацать прогу движения... как же я затрахахался все это стыковать и хотя бы как-то систематизировать. поэтому сразу определитесь, какого размера и сколько спрайтов вам будет нужно для передачи того или иного визуального действия. да и еще тебе, батенька кодер, придется самому их резать и мешать с маской, т. к. такие действия нельзя никому доверять. а то потом придется гадать, то ли твоя процедура глючит, то ли злобные графмейкеры тебе так нарезали, да еще и эскизы стерли. и лучше сразу завести себе большой блокнот, где записывать всю информацию и по спрайтам (размер, длина) и по их последовательности в блоке. и пользоваться лучше всего sprite master 5. 11 для обработки и sprite land v1. 19 для нарезания и компановки. в дополнение могу сказать следующее: спрайты перемещения мне нарисовали только раза с восьмого, и занимали они всего 9 кило.

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

а сейчас - пока.