search

Javanaise / mrboom-libretro

Mr.Boom is an 8 player Bomberman clone for RetroArch/Libretro
http://mrboom.mumblecore.org
MIT License
200 stars 59 forks source link

"submarine" new level #115

Closed frranck closed 10 months ago

frranck commented 3 years ago

Hello @reenodadada What about a submarine theme kind of level, i.e. inside a submarine from Twenty Thousand Leagues Under the Sea or on the ship from The Life Aquatic with Steve Zissou? Here is some background graphic from an existing level; that can be used to get the coordinates from the field; and to pick the palette: SOCCER Then we need bricks, in 9 steps; the bricks to the top right are used during the timeout:
PAUSE We can add layers on top; animate layers; add extra sprites. Woud be nice to have some conveyor system. What do you think @SimpleTease?

SimpleTease commented 3 years ago

Would be nice to have some conveyor system. What do you think @SimpleTease?

I realize it might be simpler after lots of thought over a week.

Bomb logic:
1. If bomb is not in middle of cell, bomb auto-moves itself using existing physics.

2. When bomb is in middle of cell, check level data to see if sitting on conveyer belt.
- If yes, reuse code as if bomb was kicked.

For players, power-ups, monsters.. I guess we add motion code.
And handle L-turn situations. Which I guess we check neighboring cells for belts also.

--->|
    |
    v

Where do we put level data that says tile is a conveyer belt?

SimpleTease commented 3 years ago

More thought into it. 2 cell tables for belt x-speed, y-speed. Then we can control each belt separately if wanted.

Add belt deltas to position. Then use existing player collision code that auto-corrects movement. Share with monsters and power-ups also.

Will see where this goes..

frranck commented 3 years ago

We can also avoid power ups from appearing on belts... Should their speed be half the normal walking speed?

SimpleTease commented 3 years ago

I think we'll have to play with speed but 1/2 seems good start. So if monsters die on belts, they don't spawn powerups? If my idea is right, belt code might be generic enough to handle anything. But that's my fantasy atm.

SimpleTease commented 3 years ago

So far I'm having bad luck with crashes. I was trying to use a modified poussage function and move the bombs myself changing offsetX based on changement timer. Checking the tile if it's treadmill (left,right,up,down).

Players and monsters would use xy_to_offset then go through basically the same routine with x,y directly. Powerups I think could do same with x,y also.

I think treadmills are doable but seems unlikely I'm the one to do it.

frranck commented 3 years ago

So far I'm having bad luck with crashes. I was trying to use a modified poussage function and move the bombs myself changing offsetX based on changement timer. Checking the tile if it's treadmill (left,right,up,down).

Players and monsters would use xy_to_offset then go through basically the same routine with x,y directly. Powerups I think could do same with x,y also.

I think treadmills are doable but seems unlikely I'm the one to do it.

no worries; the bomb code is probably the most tricky; there is some list kindoff structure that is very likely to cause crashes.

SimpleTease commented 3 years ago

So I played with it for a long while. Bombs work decently-ish-ish enough with this draft design.

belt_bombs proc near
PUSHALL

mov ebx,[liste_bombe+ebp+4+2*4] ;offset dans truc
mov dl,[truc+ebx]

mov dl,100  ;testing (###)

; 100-103 chosen completely at whim for testing
cmp dl,100
jb belt_bombs_exit
cmp dl,104
jnb belt_bombs_exit

test dword ptr [changement],0011b ;001b = player speed
jne belt_bombs_pause

cmp dl,100
je belt_bombs_move_left
cmp dl,101
je belt_bombs_move_right
cmp dl,102
je belt_bombs_move_up
;cmp dl,103
jmp belt_bombs_move_down

belt_bombs_move_left:
mov word ptr [liste_bombe+ebp+4+4*4],-1
mov word ptr [liste_bombe+ebp+4+4*4+2],0
jmp belt_bombs_exit

belt_bombs_move_right:
mov word ptr [liste_bombe+ebp+4+4*4],1
mov word ptr [liste_bombe+ebp+4+4*4+2],0
jmp belt_bombs_exit

belt_bombs_move_up:
mov word ptr [liste_bombe+ebp+4+4*4],0
mov word ptr [liste_bombe+ebp+4+4*4+2],-1
jmp belt_bombs_exit

belt_bombs_move_down:
mov word ptr [liste_bombe+ebp+4+4*4],0
mov word ptr [liste_bombe+ebp+4+4*4+2],1
jmp belt_bombs_exit

belt_bombs_pause:
mov word ptr [liste_bombe+ebp+4+4*4],0
mov word ptr [liste_bombe+ebp+4+4*4+2],0

belt_bombs_exit:
POPALL
ret
endp

===

call belt_bombs
call deplacement_bombes

cmp action_replay,0
jne nononono_onest_en_recordplayzrezerzeezr
cmp twice,1
jne nononono_onest_en_recordplayzrezerzeezr
call deplacement_bombes
nononono_onest_en_recordplayzrezerzeezr:

Easiest to test with Board and 2P Humans. Drop a bomb and watch it slowly move left. Currently once it's stuck to the "invisible belt", you can't unstick it by kicking again. Creating bomb collisions becomes very easy and suprisingly dangerous.

What'd be a goofy idea is an outer space themed level. Where the gravity (belt motion) applies to the whole stage and constantly keeps changing patterns.

I think bonus items are stored directly in the cell maps? So moving them around wouldn't work but still you could spawn them in the cell and have them be stationary. They don't seem affected by physics.

frranck commented 3 years ago

Happy new year!

What'd be a goofy idea is an outer space themed level. Where the gravity (belt motion) applies to the whole stage and constantly keeps changing patterns.

Good idea; or it could be some elevator going up and down or an amusement park ride? There must be some movie or game references to make.

I think bonus items are stored directly in the cell maps? So moving them around wouldn't work but still you could spawn them in the cell and have them be stationary. They don't seem affected by physics.

bricks are in truc: https://github.com/Javanaise/mrboom-libretro/blob/5ee93c663d8adec1e93f92d3b0a5b4920b01df2e/ai/Bot.cpp#L246

bonuses are in truc2: https://github.com/Javanaise/mrboom-libretro/blob/5ee93c663d8adec1e93f92d3b0a5b4920b01df2e/ai/GridFunctions.hpp#L319

For a starter, we could get the new level to only get accessed by the config/command line; Shall we do a develop branch; or keep using PRs?

SimpleTease commented 3 years ago

I think a development branch would be safe. Wouldn't want to be a chaos machine for the main branch with unexpected experimental foo being thrown around.

I thought more about it. I'm aiming for a truc3 since belts can't be blown up, and it could provide optional layering: brick, powerup, belt - ground.

Also I think we'll need a bomb collision fix; two bombs moving the same direction can blow each other up if timing is very precise and next to each other. Conveyer belts would make it more obvious.

frranck commented 3 years ago

Ok I created a develop branch and truc3 is a good name. :blush: