I have finished the original 65536 levels.
Scroll around and see for yourself.
I am now having trouble figureing the robot a.i.
Can someone please help?
There is a room_grid array that shows each cells surrounding walls.
http://www.retrogamedeconstructionzone.com/2020/03/decoding-berzerk-ai.html
here's the tutorial i'm trying to get.
Kevin, may i please get your attention.
I'm working hard on it but need some help too a bit.
Thanks and please give my code respect.
Scott B
I was messing around with Shamus remake or sorts last year while laid up, I do remember talking a bit about some ways to cobble together character AI.. You could try here. Building Vic20 Shamus In PlayBASIC (Blog) (https://www.underwaredesign.com/forums/index.php?topic=4469.0)
The rules outlined on Decoding the Berzerk AI (http://www.retrogamedeconstructionzone.com/2020/03/decoding-berzerk-ai.html) seem like they'd work to me.
Why did you remove the code ? How is anyone meant to help then ?
Sorry, Did'nt think anyone wanted to help.
But here it is I've got 65536 rooms but the A.i. for the robots has got me stumped.
I've tried many things many ways but I'm really really have a hard time with it.
It's suppose to use...
If x_robot < x_Player then x_robot = x_robot +1
if x_robot > x_player then x_robot = x_robot - 1
and
if y_robot < y_player then y_robot = y_robot + 1
if y_robot > y_player then y_robot = y_robot - 1
seems easy right? well, nah!
tracking is what it mostly but which way the walls stop the robots and turn them back on is baffleing.
they say it's primitive but maybe so but to me it's diffucult as heck!!!!! to match the orginal arcade.
old school maybe but until you tried I would say it's easy pleaseeeeeazzzzzzzzzzz.
Thanks for listening to my ramble but i've also tried a couple of peoples ideas on how to approach it but to no avale.
But really if anyone one can really help it would be fantastic!!!!!
So here it is again!
Thanks,
Scottie B.
from what i can see from running your code, is you seem to have the robot movement rules set correct, by looking at the link in post #1.
the issue i see is the distance the robot needs to be inside the new cell. you have it stop too early when moving from one cell to a new cell. it needs to be a min distance inside the new cell before it stops. that is why it gets stuck on the wall ends.
hope this helps.
Thanks that sort of helps a bit but...
The real issue is still just that. I can't see how to code it up and work correctly. Like as in the first link. I see it's a finite state machine also but...
I really just need help with proper movement. It's not I repeat not! just moving to and fro cells.
Anyone who could help me code it up would be greatly appreciated.
Thanks,
Scottie B.
Quotethey say it's primitive but maybe so but to me it's diffucult as heck!!!!! to match the orginal arcade.
old school maybe but until you tried I would say it's easy pleaseeeeeazzzzzzzzzzz.
Sadly that's very true, a lot of classic games were written by highly skilled engineers having to overcome so many limitations modern coders would faint. Did a quick search before and there's some disassembled versions of the game. Which might not be much use directly (say writing a convertor/emulator of the logic), but you might be able to gleem some finer logic from the code.
Only had a quick look before, will have a look later on
Links:
Map Generator Tidbits (http://www.robotron2084guidebook.com/home/games/berzerk/mazegenerator/code/)
The Story Of Robotron(playlist) (https://www.youtube.com/watch?v=RuEuCp280J4&list=PL8CAA1599951C5832&index=1&ab_channel=GlassDarkly)
Yes, That is where I learned to make the maze of 65536 rooms.
but the a.i. for the robots is what's got me so messed up.
Maybe, someone else can give it a try and show me how it's done?
I was really sticking to the original because that's what I'm shooting for.
So, If anyone could code up the robots a.i. it would be awesome!!
Thanks,
Scottie B.
i just made a demo to show only the robots 'movement' AI.
this is kept as close to the rules in the bezerk game in the website link.
the demo is all my code, with the bare minimum, just to showcase your first map screen. i didn't add shooting, as the movement was the focus.
you have a lot of code, and i just wanted to simplify the demo into a small one and to the point.
** just focus on the "Robots AI" tab in the demo.
NOTE: the robot may look funny sometimes in their movements, because they don't move closer to any walls than what they currently are, only towards and open wall.
so the robot may look like it is stuck on a wall end, but it will move when there is no wall between the player and robot.
i let the player move through walls for test purposes for the robots AI.
i know this is a small demo, but hope it helps, steve
Here's a few coin-op play through for reference. Watching the videos there's something more going on than just compute the delta X & Y / compute for collision in those directions, if none, move. Which is what I would have done from memory :)
Steve, Thanks for writing up a piece of code for me to look at.
I'll give it a spin soon. If your interested I could include you in the write up later. Just wonder how kevin is looking at it? Don't do quite know what you mean by...
"there's something more going on than just compute the delta X & Y / compute for collision in those directions, if none, (move). "??? Which is what I would have done from memory.
Kev, Could you please explain what you meant a bit.
Could you maybe show me a demo like steve a did? I don't mind doing this a a combined effort and giving credit! really don't since this one is a little tricky to me anyways.
Thanks Y'All! for the help so far in my endeavors.
Scott B.
[pbcode]
// Find the delta (distance) between robot and player
DX = PlayerX - RobotX
DY = PlayerY - RobotY
// Convert delta to movement vector /speed (in the range of -1 to 1)
MoveMentX=ClipRange(DX ,-1 , 1)
MoveMentY=ClipRange(DY , -1 , 1)
// Check grid tile ROBOT is standing in
MapGridX = RobotX / MapGridWidth
MapGridY = RobotY / MapGridHeight
// Read Map at robots position. We assume the tiles have bottom 4 bits to tag what walls that have.
// bit 0 = LEFT WALL
// bit 1 = Right WALL
// bit 2 = Top Wall
// bit 3 = Bottom Wall
Collision_WALL_BITS = Map(MapGridX,MapGridY)
// Turn our movement vector into a 4 bit mask the same as the one collision map contains
MovementMask = (MovementX<0)*1 // Check if we're moving left ?
MovementMask |= (MovementX>0)*2 // Check if we're moving right ?
MovementMask |= (MovementY<0)*4 // Check if we're moving up ?
MovementMask |= (MovementY>0)*8 // Check if we're moving down ?
// Check for collisions.
// If the tile the robot is standing upon has a WALL to the left and the robots wants top move left, we just turn it's movement off (set to zero)
if (Collision_WALL_BITS & 1 ) and MovementMask then MovementX =0
// If the tile the robot is standing upon has a WALL to the RIGHT and the robots wants top move RIGHT, we just turn it's movement off (set to zero)
if (Collision_WALL_BITS & 2 ) and MovementMask then MovementX =0
// stop y axis
if (Collision_WALL_BITS & 4 ) and MovementMask then MovementY =0
if (Collision_WALL_BITS & 8 ) and MovementMask then MovementY =0
// move the robot
RobotX+=MovementX
RobotY+=MovementY
[/pbcode]
This is basically what I was saying above. Compute the direction from the robot to the player, convert that to a movement vector. Then check for intersections with the map that prohibit the BOT bot from moving in that direction.
I'm NOT suggest this is how it's done, as it'd need more conditionals. Such as how close the robot is allowed to moved to walls and those times where the bot move diagonals between tiles. If you watch the videos the bots have delays and seem to move every couple of frames also. I dunno
Thanks Kev, That's cool stuff. Your right there is a finite state machine thingy going on there I think.
But that helps with movement more like steve has done a bit too.
So, I'll look it over for a bit before moving on but really thanks a bunch guys and I'll get back to you later.
Bye, for now.
Peace is always in!!!
Scott B.
Scott,
was thinking about this the other day and if you strip away the game and just work on the logic for the character within one section of the grid/map. Then work out/tweak the bot movement to follow the mouse on the various states. Inside the same grid, bellow/above/left and right of it.
Although watching the video above there does seem to be some oddball cases where the bot doesn't do what I'd expect....
Kevin, I got your idea up and running a bit but now I'm having trouble once
I try to turn arrays to floats for timing variables game speed it malfunctions.
What do you think the problem may be? This time I'm really lost as soon a I change it
it flaws out. Have a look.
Thanks,
Scott B.
Kevin can you show me with a working upgrade with robots moving???
Too busy with [plink]Website (https://www.underwaredesign.com/forums/index.php?topic=4651.0)[/plink] stuff currently.
i did look at this some time ago and posted a demo. i think you are on the right track but just need to modify the robots a bit to be in the tiles when they cross over, and decide if they want to move even if there is a wall in the direction they want to move.
you have them stop moving if there is a wall in the direction they want to move. just add a bit more decisions they can make to move more like the youtube game video kev posted.
also, the example you posted was trying to open in fullscreen mode, but this failed on my computer (too small), and when this happens playbasic defaults to the screen size in the project > settings > screen tab.
so instead of a 320 * 200 fullscreen, this failed and instead opened default screen of 800 * 600 window. i have an RTX 3070 video card.
maybe make a bigger screen and you can scale the graphics up to suit, then make this bigger size fullscreen if it is compatible. you can use command ScreenModeExist() to check before using OpenScreen() command if you want to use fullscreen mode.
The maze generation is right on que. Though the secreen can be adusted.
My real question is robot A.I. Chase algorithm limited by walls.
A better option on modern systems will be a stretched window
[pbcode]
X_Screen_Res = 320
Y_Screen_Res = 200
Color_Mode = 32
Windowed_Mode = 1
OpenScreen X_Screen_Res,Y_Screen_Res,Color_Mode,Windowed_Mode
LR_ScaleWindowToDeskTop()
SetFPS 60
do
cls 0
lockbuffer
for ylp=0 to GetSurfaceHeight()-1
for xlp=0 to GetSurfaceWidth()-1
DotC xlp,ylp,(xlp*ylp)*Offset
next
next
unlockbuffer
offset++
sync
loop
type tWindow_RECT
X1,Y1
X2,Y2
endtype
linkdll "user32.dll"
LR_SetWindowPos(hwnd,hWndInsertAfter,x,y,cx,cy,wFlags) alias "SetWindowPos" As integer
LR_GetWindowRect(hwnd,RectPointer) alias "GetWindowRect" As integer
LR_GetClientRect(hwnd,RectPointer) alias "GetClientRect" As integer
Endlinkdll
Function LR_ScaleWindowToDeskTop()
// Get the Desk top width/height
local dtw=GetDesktopWidth()
local dth=GetDesktopHeight()*0.96
// Get the PB screens size
local w#=GetScreenWidth()
local h#=GetScreenHeight()
local Ratio# = dth / h#
w# *=Ratio#
// Get the PB screens window Handle
local hwnd=GetScreenHandle()
local Xpos = (dtw - w#)/2
; Stretch the window to the size users display size
LR_SetWindowPos(hwnd,0,Xpos,0,w#,dth,0)
; Resize PB's GFX viewport to screens (the window) new client area
StretchGFXscreen
Endfunction
[/pbcode]
Scottie: Dude was watching this video again.. Originally I didn't get why some of the bots would not move towards the player; even when it was clear they should The spice seems to be all in the proximate to the walls. So if the bot is near a wall; then it's unable to move along the axis in either direction. Which I remember reading about before, but glossed over.
So we know bots are moving towards the player, at about half the speed of the player moves. To be it looks like they handle the X and Y axis separately. So we could compute a delta between the Bot and Player on the X axis, forming a direction the bot needs to move in order to makes it's position the same as the player. So some value that represents LEFT =-1 / RIGHT=1 or STAND STILL=0 . We do the same for the Y Axis.
After we have the movement directions; we then check if these are cancelled out by obstructions from the map.
FOR EACH BOT
Compute delta X.
X_DELTA = PlayerX - BOTX
; form our movement direction along this axis
X_AXIS_MOVEMENT_DIRECTION = (X_DELTA < Player_Bounding_BOX_LEFT_X ) * -1
X_AXIS_MOVEMENT_DIRECTION+= (X_DELTA > Player_Bounding_BOX_RIGHT_X )
; Repeat this for the Y AXIS
; Check the bounding box of the MAP tile the bot is standing within
Map_X = BOTX / Map_TILE_WIDTH
Map_Y = BOTY / Map_TILE_HEIGHT
; Assuming the bottom 4 bits represent what walls are present within this tile (say bit 1=left / 2 = right / 3 =floor / 4 ='s floor)
ThisTILE = COLLISION_MAP(Map_X,Map_Y)
if (ThisTILE)
// Check if this tile has either a LEFT or RIGHT wall (bottom pair of bits)
if (ThisTILE and %0011)
// This tile has either a LEFT or right wall, so we'll check how close we are and cancel out the movement if need be
BOT_X_MODULUS = mod(BOTX / Map_TILE_WIDTH)
if (ThisTILE and %0001)
if BOT_X_MODULUS< MIN_DISTANCE_FROM_WALL
X_AXIS_MOVEMENT_DIRECTION =0 // Limit movement along this axis
endif
endif
// does this tile has a RIGHT wall ??
if (ThisTILE and %0010)
// if it does; is the bot too close to that wall ?? if so; restrict movement on this axis
if BOT_X_MODULUS> (Map_TILE_WIDTH - MIN_DISTANCE_FROM_WALL)
X_AXIS_MOVEMENT_DIRECTION =0 // Limit movement along this axis
endif
endif
endif
// SAME LOGIC FOR THE Y AXIS
endif
// MOVE BOT
BOTX += X_AXIS_MOVEMENT_DIRECTION * MOVEMENT_SPEED
BOTY += Y_AXIS_MOVEMENT_DIRECTION * MOVEMENT_SPEED
This doesn't cover all of it of course as there seems to be situations where the bots will stand near each other away from ways. Maybe they check the wall proximity regardless if whether the wall is present or not..
I dunno... BOTS need full collision so they'll need to be checked against the others for impacts, walls and all projectiles (BOTS and Players) which is what stops them all from just ended up in the same location as the player.
Could you please intergrate I will claim level design was done by me and give you robot a.i. credits.
I would love to see a working copy.
Thanks Scottie B.