Bomber Kat - классический бомбер с котиками! (3 стр)

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

я получил свои "стандартные" нейрослопоспагетти с глубокими if if if else, перенося и дублируя логику в разных местах. Ну что ж... я знал на что шёл.

мои поздравления!
Не проще было меня попросить модифицировать версию ZenGL под нынешний iOS?

кого попросить?
я думаю, у тебя есть занятия по-интереснее, чем обеспечивать поддержку сторонним коммерческим продуктам

хм. походу дела, с пользой нужно агента для конвертации так использовать:
1) писать архитектурную основу руками. Классы, интерфейсы, прочее
2) давать команду на конвертацию конкретных частей
3) следить за тем, чтобы конвертация была максимально близкой от исходника (экономит время на сравнение)
иначе, фантазия ии-шку очень далеко от оригинала может увести

skalogryz
> я думаю, у тебя есть занятия по-интереснее
вообще-то это тоже интересно. Просто ни кто не спрашивал о таких возможностях, а сам я не заморачивался этим потому что ни кому не нужно. )))

skalogryz
> Ну т.е. чтобы что-то получить толковое от китайской комнаты, китайский придётся таки выучить.
по-классам заставил переписать код, так чтобы его можно было сопоставить (и отладить), при сравнении с паскалем.

skalogryz
> я ожидал использование AnimatedSprite2d.
дальнейшее курение манула, показало. Что ИИ-шка так и не довела до ума перенос "своего формата" спрайтов в Годотный.
кроме анимации (чем занимается AnimatedSprite2d), нужно ещё использование ресурса SpriteFrames. (тогда и спрайты можно удобно редакторивать в годоте).

Склоняюсь, что после порта игры на Годот (для мобилки), таки сделаю порт на юньку (для tvOS)

upd
Нейро-эпилепсия!

Исходные данные. Есть две анимации в разных sprite-sheet-ах:

door_open/
  door_open

door_closed/
  door_closed

это два разных ресурсных файла. Их можно объединить в один

door/
  open
  closed

просто будет один файл.  (с потенциалом использовать разные двери)

даю команду, объедини в один. Выхлоп

door/
  open_0
  closed_0

а в коде ещё дописано - выкусывать всё то, что перед "_" и использовать его как имя. (ну т.е. "open_0" -> "open")

зачем?! это какой-то стандарт?! работа ради работы.

интересная проблема.

в исходном варианте, кадры анимацию могут зеркалится в зависимости от направления юнита. (если идёшь на восток, возьми кадр хождения на запад и отзеркалься).
Базовый функционал для низкобюджетных 2д игр.

Но в паскаль версии, свойство "отзеркалься" это свойство отдельного кадра в анимации.
В Годот, "отзеркалься" это не свойств кадра, и не свойство последовательности кадров, это свойство уже непосредственно аниматора.

ИИ на это успешно забил (т.к. для ГГ отрисованы все 4 направления, что ИИ взял за истину, и скопипастил для всех остальных юнитов)

правлю руками, чо (код отвечающий за актуализацию аниматора). Мне так проще.

PS:  переправка с "творчества ИИ" на "ближе к паскалю" разрулила проблемы с кодом (н.р. ракеты противников летают как положено, а не только на 2 ближайшие клетки. Черепашек можно толкать). Подспудно разрулились проблемы с отрисовкой (одна из которых упомянута выше).
+ разобрался (???) как вносить правки в маппинг спрайтов.

Наверное ИИ чё-то там и ускоряет. Потому что, чистого, сравнения уже не получится. Т.к. не с нуля пишу. Но после бодрой разработки вайбкодингом, всё-равно приходится отлаживать и править руками.

рассуждения ИИ-шички, на запрос "сделай мне хорошо, на unity":

итоговый проект не запускается. Валится с ошибкой на старте:

upd
я предложил ИИ отказаться от подхода: "всё делать в рантайм", на дизайн-тайм со сценами.
При конвертации первого экрана, модель подтащила пакет TextMeshPro, на что unity ругнулся предупреждением, о том, что пакет, вообще-то уже устарел.
Не успевают модели тренировать!

но первый экран сконвертирован. И уже можно подгонять его руками:

проект всё ещё падает при запуске

очевидно, что сконвертировать спрайт-шиты как спрайт-шиты, у ИИ мозга не хватило, и все они легли как runtime создание спрайтов.

Но ничего, сейчас будем убедити!

нда... он калобласил изрядно.
0) он создал проект для юнити, коих я никогда не видал - без сцен!
игра пыталась запуститься за счёт AfterSceneLoad (при отсутствии последних).
1) ладно, я его заставил создать сцены (главное меню, экран игры).
2) но сама игра всё ещё инициализировалась в ран-тайме этого самого AfterSceneLoad.
3) анимации он пытается грузить из годот формата руками (вместо Animation Clip+Animation+Sprite)
полное отсутствие соображалки.

Сначала тратишь половину токенов не "конвертацию", а потом ещё лимита 4-6 до доведения до человекочитаемого состояния.

Вернулся в проекту и решил забросить юнити.

Конвертация далась ему очень плохо. С полпинка не заиграло, с ещё больше пинков - не заиграло.
Но главные вилы, как ни странно идут от юньки. Т.к. юнити делает лок на проекте, и редактор второй раз на открытом проекте уже не запустить.
А ИИ постоянно пытается пересобрать проект, чтобы убедиться, что "ошибок нет". Это означает, что редактор нужно закрыть мне.
Подождать ИИ-шку, и потом открывать юньку снова, что само по себе процесс не скорый. Задолбало. (в Годот такой бюрократии нет)

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

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

И таков код был изначальный:

  private void UpdateCamera()
  {
    if (_camera == null || _campaign == null)
      return;

    var core = _campaign.Current.Core;
    var viewportSize = GetViewportRect().Size / _camera.Zoom;
    var fieldSize = new Vector2(core.Width * TileSize, core.Height * TileSize)

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

При добавлении мультиплеера, ИИ разумно заявил, что вообще-то у нас сейчас игра без кампани, и "кор" можно получать из других объектов. (да, он добавил спец объект для локального мультиплеера) поправив код следующим образом:

  private void UpdateCamera()
  {
    if (_camera == null || _campaign == null)
      return;

    var core = ActiveCore;
    var viewportSize = GetViewportRect().Size / _camera.Zoom;
    var fieldSize = new Vector2(core.Width * TileSize, core.Height * TileSize)

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

  private void UpdateCamera()
  {
    if (_camera == null || _campaign == null)
      return;

    var core = ActiveCore;
    var viewportSize = GetViewportRect().Size / _camera.Zoom;
    var fieldSize = new Vector2(core.Width * TileSize, core.Height * TileSize)
    if (IsLocalMultiplayer)
    {
      // вольная интерпретация от меня:         
      _camera.Position = иди в центр, дура; 
      return;
    }

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

  private void UpdateCamera()
  {
    if (_camera == null )
      return;

естественно, я ему не стал говорить, поправил сам.

Подождём очередной Ofigabel 100500 от очередной ИИ конторы. Это не единственная проблема оказалась, то это то, с чем я разобрался и вот отчитываюсь.
Но так или иначе, желаемый режим игры он добавил, два и более игроков, действительно играют.

собственно не отходя от кассы (лимит же токенов не кончился... даже до половины не дошёл)

состребовал написать бота:

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

Беги! Спасайся!

И история повторяется: "не работает, так и так". "да, господин, не работает. Сейчас исправлю господин, мамой клянусь! Всё готово, господин!".

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

elcar
врят ли.
проблема в проверке достиг он цели, или нет.
но пока я это отлаживал, обнаружил, что галлюцинации нанесли ещё больший вред ранее. Более фундаментально.

Описать это можно так. В паскаль версии центр клетки это .5, .5.
ИИ при конвертации он поменял логику, что центр клетки .0, .0. В некоторых ответственным местах он начинает эту фигню компенсировать тем, что добавляет недостающие .5. (например при расстановке спрайтов)

В итоге, я руками, переношу движок. Поверх того, что уже есть (благо ооп, и я уже раньше потребовал структуризации по аналогии с паскалем), но так или иначе руками.

Вся интеграция с Годот остаётся, как есть - нейрослопом. (хотя я и там правки руками вносил, местами)

сделал сборку и погонял на андройде.
что удивило, так это лютая чувствительность (не оптимизированность?) годота на андройде.

Изначально вся карта:

целиком рисовалась на отдельных спрайтах (Node)

при запуске на андройде FPS просел, где-то до 4-10fps в секунду. Замеров нет, но на глаз видно.

напряг ИИ чё-нить посоветовать, и первое, что он предложил: "а давай мы это будем на TileMapLayer делать?" (классика жанра ИИ: первый вайбкод всегда не идеален)
Оке, ИИ переписал, и о чудо FPS стал нормальным 30+ . (опять же без замеров, но на глаз тормозов не видно).

Но, так или иначе, 256 отдельных спрайтов дают такую просадку FPS, по сравнению с отрисовкой того же объёма через TileMapLayer?!
это ну очень странно. (один Node рисуется 70ms?! жесть же)

ЗЫ: ну и запуск приложения тож так себе. 15 секунд (10 секунд время между "стартовой иконкой" и "лого готод"... ещё 5 секунд "лого готод"). Как это оптимизировать вообще не понятно.

взрывы и разрывы тел как в оригинале. здорово получилось