Танковый TDS «Операция "Свинцовый туман"» [SMD]

[Томахомэ]

Идея возникла случайно, как своеобразный игрокроссовер вольного сиквела фильма "Белый тигр" Карена Шахназарова и сонгфика по перепевке знаменитой песни про трёх танкистов в исполнении группы "Свинцовый туман" (в её-то честь я игру и назвал). Герои игры - элитное танковое подразделение, каждый из членов которого по имени, внешности и характеру идентичен соответствующему участнику "Свинцового тумана" (правда, в игре все они будут сильно "омоложены" по сравнению со своими реальными прототипами - примерно того возраста, в котором каждый из них находился где-то в 90-х, в крайнем случае - в 2001-м; а также музыка и поэзия у них из профессии превратятся всего лишь в хобби).

Я, конечно, как человек, с творчеством группы хорошо знакомый, понимаю, что трудно представить двух более несовместных друг с другом вещей, чем "Свинцовый туман" и война, однако герои игры, как пацифисты по убеждениям, будут не участвовать в войне, а предотвращать её.
Дело в том, что, по сюжету, где-то примерно в наше время пророчество Ивана Найдёнова из "Белого тигра", спустя 70 с лишним лет, всё-таки сбылось, и танк-призрак всё таки вернулся, начав нападать на пограничные посты по обе стороны российских границ, будто устраивая провокацию и пытаясь стравить нас со странами, на границе с которыми произошли инциденты.
Во избежание большой войны чуть ли не со всеми своими соседями сразу (если не вообще мировой, возможно даже ядерной) команде героев (приглянувшихся армейскому начальству тем, что они не только единственные выжили на родной базе, когда та подверглась атаке танка-призрака, но и, казалось бы, чуть было не уничтожили его, вынудив своим нехилым отпором временно отступить) было приказано добить наконец таинственный танк, пока он не успел добиться своей цели.
Казалось бы, с помощью современных оружия и техники (учитывая что внешне танк со времён своего прошлого появления в нашем мире нисколько не изменился, оставшись всего лишь "Тигром" времён Второй Мировой), да ещё и с таким экипажем, как команда наших героев, сделать это особого труда не составит - да только танк оказался совсем не так прост, каким казался "в прошлый раз". Каждый раз, стоит только нашим героям на определённое расстояние приблизиться к нему, их тут же каким-то мистическим образом перебрасывает в некое странное измерение-"поле битвы", где им приходится встретиться с порождённой таинственным танком настоящей фантомной вермахтообразной армией, а сам танк-призрак в таких измерениях обретает магическую способность трансформироваться в самые ну уже совершенно невообразимые гигантские вундервафли. Они-то и послужат боссами в конце каждого уровня.

Среда разработки - BasiEgaXorz. Планируемые изменения:

• Достать полностью оригинальную качественную графику (пропорции размеров спрайтов и прочих элементов графики при этом должны быть побольше - примерно такими же, как в Shock Troopers) - это, пожалуй, один из самых важных элементов
• Добавить фон
• Разумеется, сделать врага активным и внести в игру, помимо него, ещё кучу других видов противников - а то какой же без этого геймплей
• Вставить код создания при появлении спрайта взрыва зоны вокруг него с определённым радиусом, попав в которую, ближайшие находящиеся рядом цели также получают повреждения
• Обеспечить независимость прицеливания от перемещения (т. е. дать танку возможность одновременно стрелять в одну сторону и двигаться в другую, как это было в аркадных версиях серии Ikari и игр T.N.K. III, Heavy Barrel, Time Soldiers и т. д.)
• Добавить другие виды оружия, главным образом - установленный на башне дистанционно управляемый оттуда пулемёт (прицеливание которого будет независимо не только от движения танка, но и от прицеливания башни - хотя в случае с последней независимость эта будет лишь частичной, т. е. при повороте башни вместе с ней в ту же сторону на тот же угол автоматически повернётся и пулемёт) - дефолтное вспомогательное оружие, которым можно будет крыть врага, пока в орудие после выстрела относительно долго закладывается новый снаряд
• Создать кучу охренительно огромных уровней со сложной лабиринтообразной структурой (по которым кстати, можно будет перемещаться не только вперёд, к боссу, но и назад, от него - что в аркадных играх редкость - дабы подзаработать побольше очков и бонусами затариться за счёт противников, респаунящихся на ранее пройденных игроком территориях за время его отсутствия, да и в случае слишком долгой задержки на одном и том же отрезке уровня противники тоже начинают респауниться и вновь осаждать игрока, чтоб не тормозил) и как минимум несколькими возможными путями прохождения (как в Metal Slug 3 и некоторых других более поздних частях серии)
• В дальнейшем список будет со временем всё больше дополняться и расширяться.

Скриншоты и исходники прикреплены.

[lelikcr]

Ух. Амбициозно.  Скачал. Открыл через Gens32Surreal поиграл танком верней по руководил что ли. Мягкое отзывчивое управление. Даже удалось поехать под углом 45 градусов.
играл на джойстике похожим на хбокс -360. И на стике хорошо и на крестовине тоже. Это я для статистики если что, может вам нужно.

[Томахомэ]

Мягкое отзывчивое управление. Даже удалось поехать под углом 45 градусов.
играл на джойстике похожим на хбокс -360. И на стике хорошо и на крестовине тоже. Это я для статистики если что, может вам нужно.

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

На основе, кстати, этого движка я параллельно и jRPG попиливаю (Подробнее здесь и здесь).

[emulander]

Среда разработки - BasiEgaXorz

Ну почему на bex, это же почти говно мамонта ископаемое, в котором и багов куча осталось. Почему то все кто пишет или пытается писать под smd на бэйсике пишут именно на BasiEgaXorz, но он ведь уже почти как 10 лет заброшен, есть же идейный продолжатель Second Basic, который как минимум не хуже, по большей части совместим с bex, развивается и автор отзывчивый оперативно фиксит и подсказывает если что. Но вот форум пустует, народ не тянется и все, не знаю почему так, видимо дело в статичности людей, видимо важнее наличие комьюнити и пачки примеров.

[Томахомэ]

Ну почему на bex, это же почти говно мамонта ископаемое, в котором и багов куча осталось. Почему то все кто пишет или пытается писать под smd на бэйсике пишут именно на BasiEgaXorz, но он ведь уже почти как 10 лет заброшен, есть же идейный продолжатель Second Basic, который как минимум не хуже, по большей части совместим с bex, развивается и автор отзывчивый оперативно фиксит и подсказывает если что. Но вот форум пустует, народ не тянется и все, не знаю почему так, видимо дело в статичности людей, видимо важнее наличие комьюнити и пачки примеров.

Рад бы на SecondBasic перейти, только вот в дальнейшем планирую создать также CD- и 32X-версии своих проектов, а SB такой возможности пока не даёт (хотя разраб и обещает их поддержку потом добавить).
jRPG свою, правда, я на SB уже перевёл, зато получил в результате переноса странный баг при движении персонажа вправо и вниз, которого в BEX-версии не было - в первом случае спрайт принимает позицию, изначально предназначенную для диагонального движения вправо/вниз (Плюс, мало того, что к тому же движется в несколько раз быстрее, чем при движении во всех остальных направлениях - перелетая даже за правый край экрана - так ещё и смещается при этом на несколько пикселей вниз), а во втором - позицию для движения влево/вниз. Как это выглядит, можно посмотреть на видео по ссылке.

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

[Werton]

jRPG свою, правда, я на SB уже перевёл, зато получил в результате переноса странный баг при движении персонажа вправо и вниз, которого в BEX-версии не было - в первом случае спрайт принимает позицию, изначально предназначенную для диагонального движения вправо/вниз (Плюс, мало того, что к тому же движется в несколько раз быстрее, чем при движении во всех остальных направлениях - перелетая даже за правый край экрана - так ещё и смещается при этом на несколько пикселей вниз), а во втором - позицию для движения влево/вниз. Как это выглядит, можно посмотреть на видео по ссылке.

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

Код: [Выделить]

If j.0=0 And j.1 And j.3 Thenна

Код: [Выделить]

If j.0=0 And j.1=1 And j.3=1 Thenпроверял на крайней версии 2.3.43, думаю стоит написать багрепорт, надеюсь напишите, потому что мне лень

[Томахомэ]

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

Код: [Выделить]

If j.0=0 And j.1 And j.3 Thenна

Код: [Выделить]

If j.0=0 And j.1=1 And j.3=1 Thenпроверял на крайней версии 2.3.43, думаю стоит написать багрепорт, надеюсь напишите, потому что мне лень

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

[Werton]

Этот бэйсик начал щупать только сегодня и чего то мне кажется что

это я про бэйсик, если что.
Похоже он очень сырой и полон багов 
этот код

Код: [Выделить]

Print SpritePosX(character_top)>128
Print SpritePosY(character_top)>128
Print SpritePosX(character_top)>128 And SpritePosY(character_top)>128выдает

Код: [Выделить]

1
1
0однако это

Код: [Выделить]

x = SpritePosX(character_top)>128
y = SpritePosY(character_top)>128
print x
print y
print x And yуже выдает

Код: [Выделить]

1
1
1Темную сторону логики в этом вижу я
Я подумал что тут возможно используется взятие выражений в скобки для указания приоритета вычисления, но нет, это

Код: [Выделить]

Print (SpritePosX(character_top)>128) And (SpritePosY(character_top)>128)это тоже дает 0
поэтому либо пользоваьтся в таком виде

Код: [Выделить]


If j.2=1 And j.0=1 And j.1=0 Then
PropSprite character_top,292,0
PropSprite character_bottom,325,1
Body=4
x = SpritePosX(character_top)>128
y = SpritePosY(character_top)>128
If x And y Then
ShiftSprite character_top,-1-Speed,-1-Speed
ShiftSprite character_bottom,-1-Speed,-1-Speed
EndIf
EndIf
А лучше вообще не пользоваться, кривая софтина, еще вместо того чтобы писать, синтаксис еррор тупо падает, нафиг такое программирование 
_{ушел щупать SGDK}

[Томахомэ]

поэтому либо пользоваьтся в таком виде

Код: [Выделить]


If j.2=1 And j.0=1 And j.1=0 Then
PropSprite character_top,292,0
PropSprite character_bottom,325,1
Body=4
x = SpritePosX(character_top)>128
y = SpritePosY(character_top)>128
If x And y Then
ShiftSprite character_top,-1-Speed,-1-Speed
ShiftSprite character_bottom,-1-Speed,-1-Speed
EndIf
EndIf


Слава богу, что хоть теперь нормально пахать прога начала, а также что на форуме SecondBASIC есть специальная тема для докладов о багах.

[Томахомэ]

проверял на крайней версии 2.3.43, думаю стоит написать багрепорт, надеюсь напишите, потому что мне лень

Написал. И, надо же, кое-какие баги действительно нашлись.

[TiberiyLTim]

Похоже он очень сырой и полон багов

С херали ты юзаешь такие неправильные алгоритмы как "Print SpritePosX(character_top)>128" - оно и не должно работать. Напечатать координату такого-то спрайта больше 128? лол. В данном случае забагован твой код, а претензии не обоснованы. Очень важно тут соблюдать условности документации вплоть до кавычек, если они предусмотрены.

SecondBASIC же заточка BEX (переиначивание некоторых VDP решений) под нужды одного игродела, который на нём особо ничего не смог добиться, перешёл на SGDK. BEX хоть и имеет некоторые баги, но они легко решаются, если знаешь о них: не работает деление на 2, первый спрайт не уничтожается и т.д. Первый спрайт можно не юзать или вообще не уничтожать, а прятать за границами экрана, что оптимальнее и правильно в программировании для слабых платформ. А делить можно на переменную, которая может быть и 2. Вот так и обошли проблемы. Ради их решения стоит менять инструмент на узколобую заточку под свои нужды одного не самого прошаристого игродела? Нет... Тогда лучше сразу на SGDK.

[Werton]

С херали ты юзаешь такие неправильные алгоритмы как "Print SpritePosX(character_top)>128" - оно и не должно работать.

Напечатать координату такого-то спрайта больше 128?

ржу нимагу, алгоритмы, да еще и неправильные? А ты точно режиссер программист? Парень, это "a > b" называется простым выражением сравнения, которое возвращает (как функция, чтобы тебе понятнее было) значение булевого типа "True" или "False", а так как в этом бэйсике нет булевого типа и вместо него используется Integer, то соответственно вышеуказанное выражение возвращает 1 или 0. Думаю объяснять про то что функция Print в бэйсике использует неявное преобразование в String и может принимать как аргумент данные типа Integer тебе не надо? Поэтому "Print SpritePosX(character_top)>128" эквивалентно "Print 1" или "Print 0" в зависимости от результата логического выражения. А ты поди думал что можно только так писать if a > b then... 

[TiberiyLTim]

Вообще-то тебе и пишу, что тут не полный BASIC, а его ограниченная вариация BEX, где такое выражение НЕ работает, т.к. изначально не запланировано.

[Werton]

.

Вообще-то тебе и пишу, что тут не полный BASIC, а его ограниченная вариация BEX, где такое выражение НЕ работает, т.к. изначально не запланировано.

Писать то ты пишешь, но видимо не думая, потому что, то что ты обозвал моим "забагованным кодом" (тот что с Print'ами)  как раз работает (нет, погоди, еще раз для закрепления, специально для тебя - "такие неправильные алгоритмы как"  "Print SpritePosX(character_top)>128" - РАБОТАЮТ! даже в этом "не полном BASIC, его ограниченной вариация BEX", так понятно?  ), как и должно, а почему они не могут не работать я и разъяснил выше, просто ты не догоняешь и пишешь ахинею.
А не работают(а точнее неправильно работают) сложные логические выражения (в данном случае логическое умножение со сравнением, в которых используется SpritePosX, остальное не проверял) вида (SpritePosX(a)>100) And (SpritePosY(b)>100), которое при выражениях (SpritePosX(a)>100) равному логической 1 и и при (SpritePosY(b)>100) равнму логической 1, возвращает логическое 0. Т.е итоговое логическое выражение "1 And 1" равно 0, вместо 1 (это для упрощения показано, в таком виде оно как раз работает).
Какой бы этот бэйсик не был урезанный, такие "сложные" выражения должны работать, либо компилятор должен выдавать ошибку синтаксиса не позволяя использовать в сложных выражениях SpritePos, если он этого не умеет, и в документации должно быть описано, но этого нет, поэтому вызывает недоумение пользователей.

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