“В реальности все не совсем так, как на самом деле” (c)

Увидел на форуме zx-pk.ru (не регистрируюсь там потому что “опись-протокол-сдал-принял-отпечатки пальцев“) как уважаемый Slider интересуется в курсе ли я о новой графики для игры.

Сразу скажу - да, мы некоторое продолжительное время c релиза альфа-версии игры (2019 год однако! Как время быстро летит…) общались с Moroz1999 по поводу новой графики, он сделал невообразимую красоту, и даже были какие-то подвижки с моей стороны по ее адаптации, но оказалось не все так просто, как кажется на первый взгляд, а потом внезапно все заверте…

Исходники игры открыты, их можно найти тут актуальная ветка ver-1-2-3 или (на момент написания странички) аналогична master.

Я неоднократно говорил что лицензия у игры GPL3, поэтому не против, если кто-нибудь адаптирует игру под другие платформы, переведет на другие языки, с другой графикой, музыкой, добавит расширенную память 128к… Со своей стороны готов подсказать по движку если будет нужно.

О сборке

Сборка заточена, к сожалению, под MacOS - в папке /bin лежит несколько скомпилированых под MacOS программ - компилятор, упаковщик, несколько конвертеров на Python3. Думаю, довольно легко можно адаптировать под Linux, насчет Win не знаю.

Чтобы работали скрипты нужно установить виртуальную среду окружения питона командой

source ./venv/bin/activate

При запуске скриптов make_tape / make_trd / make_sna происходит полная пересборка всего проекта:

• png-файл /data/maps/tiles_many.png конвертится в /output/tiles.scr формата screen (фактически бинарник)
• файл /output/tiles.scr нарезается на тайлы и сохраняется в /output/tiles.bin
• файл формата Tiled ./data/maps/laboratory3.tmx парсится как карта и сохраняется в /output/map.bin
• код компилируется и вместе со статическими данными собирается в файл /output/static.bin
• изменяемые данные собираются в файл /output/dynamic.bin
• static и dynamic файлы сжимаются упаковщиком zx7 и сохраняются соответственно в static.bin.zx7 и dynamic.bin.zx7
• на последнем шаге сборки получившиеся три файла размещаются в образе памяти zx-spectrum и нарезаются на кусочки в зависимости от итоговой цели:

например так:

ORG PROG_ADDR

STATIC_BIN:
incbin "static.bin"
STATIC_BIN_END:

DYNAMIC_BIN:
incbin "dynamic.bin"
DYNAMIC_BIN_END:

DYNAMIC_BIN_PACK:
incbin "dynamic.bin.zx7"
DYNAMIC_BIN_PACK_END:

SAVESNA "cell3326.sna",PROG_ADDR

О конвертации графики и описании ячеек

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

Я делал игру под впечатлением от SpaceStation 13, где карта довольно квадратно-гнездовая. Стена - это просто одна ячейка, без скруглений по бокам.

В новой графике же у игры визуально появляется 2.5D измерение. Например, возьмем одну ячейку стены на старой карте… В новой графике это будет целых 8 ячеек = верх-лево / верх-право / низ-лево / низ-право / верх / низ / право / лево.

И их все надо описать…

Вот например содержимое файла описания мягкой стенки soft_wall.asm:

SoftWall.spr: equ #06

  MODULE SoftWall

    SETUP_CELL_TYPE_N Soft_wall_name, soft_wall_script
  
soft_wall_script:
  IfVar Vars.var_act, do_get, get_script
  IfVar Vars.var_act, do_drop, drop_script
  goto no_way_script
  
drop_script:
  IfVar Vars.var_item_id, Shard.spr, soft_wall_break
  IfVar Vars.var_item_id, Nippers.spr, soft_wall_break
  shiruFX 17
  CallScript action_ring_explode
  ShowText Soft_wall_hit_mess
  goto no_way_script

get_script:
  shiruFX 2
  CallScript action_ring_explode
  ShowText Soft_wall_hit_mess
  goto no_way_script

soft_wall_break
  shiruFX FX_Cutt
  SetMapCell SoftWallBreak.spr
  ShowText Shard_to_soft_wall_mess
  goto no_way_script

  ENDMODULE

В новой графике таких файлов придется делать 8 штук :) Допустим, get_script еще можно унифицировать для этого типа ячеек, но soft_wall_script, soft_wall_break и drop_script который вызывает предыдущие две функции, придется писать уникальные - ячейка soft_wall_top_left должна заменяться именно на верхнюю_левую_стенку_с_дыркой. А потом еще 8 файлов для стенки с дыркой.. И еще 8 для керамита, например. И кое-где встречаются дополнительные Г-образные спрайты стенки, которые тоже надо писать.

Так как клепать такие файлы дико лениво, периодически всплывают разные мысли насчет оптимизации - от “добавить в описание предмета спрайт on_destroy и унифицировать уничтожение итемов” до реализации зачатков Entity Component System на ассемблере… Пока ни одна из возможных реализаций мне не понравилась…

Например настенный компьютер, или сейф получается вмонтирован в стену - а что с другой стороны (керамит? мягкая стена? тоже сейф? делать у спрайтов две стороны и переворачивать карту? ). Придется доработать код чтобы не давал возможность использовать предмет если игрок стоит с неправильной стороны…

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

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

p.s. идея с поворотом карты любопытная…

p.p.s. вот вам бонус (ветка extended-graph в репозитории git)

p.p.p.s. а может нейросетка поможет все это сгенерить…