Most silly game ever ...

Game development specific discussions.
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

so, the droid will be in constant motion, no stopping then rotating to correct facing, then proceeding, huh? that presents a whole lot of trickiness! Hmmm, don't see how you can do it be scanning one ray at a time - need to get the entire picture clear in bots mind before can path a way taking into account its rate of turn... can it slow down and speed up?

ADDITIONAL:
how is the 'world' represented in the computer" a grid? as polygon objects?

it would be easier to scan and determine edges/corners if everything was polygons... but if a grid, then will have to make your own polygons from the scan points (which do not have to be extremely 'fine' - can probably get away with 1-5 degrees apart, depending on the size of everything, etc) - and when a point is found that does not fit on the current slope of the line of the previous points, then you found a corner... now refine the scan between the last point scanned and the current one so you can find exactly where the corner is.
Image
Last edited by leopardpm on Aug 23, 2016 23:29, edited 1 time in total.
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Most silly game ever ...

Post by Tourist Trap »

leopardpm wrote: can it slow down and speed up?
It can slow down, speed up, yes. But not instantly. It's maybe clearer by simply watching the mobile first parameters.

Code: Select all

type MOBILE extends BOX
    declare constructor()
    declare operator cast() as integer
    declare property RightNose() as P2D
    declare property LeftNose() as P2D
    declare property MobSpeed() as single
    declare property MobSpeed(byval as single)
    declare sub RefreshNosePosition()
    declare sub RefreshDetectionDevicePosition()
    declare sub RotateMob()
    declare sub MoveMob()
    declare sub SetCourse()
    declare sub DrawMob()
    declare sub DrawMobVisualGuide()
    	'________________________MOBILE
        as single   _mobSpeed			''
        as single   _mobRotationRate		''
        as double   _headingAngle			""
        '
        as double	_instantCourseToTargetAngle
        as P2D		_targetPoint(any)
        '______________________DETECTOR
        as DETECTOR	_mobL0DetectionDevice
        as DETECTOR	_mobR0DetectionDevice
        '_____________NOSE VISUAL GUIDE
        as P2D		_rightNose
    	as P2D		_rightNoseforward
        as single	_rightNoseDistanceToCenter
        as ubyte	_rightNoseBlinker
        as P2D		_leftNose
    	as P2D		_leftNoseforward
        as single	_leftNoseDistanceToCenter
        as ubyte	_leftNoseBlinker
    static as ulong		neutralColor(any)
end type
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

I see a rotation rate in there, but no 'acceleration' variable....

yours is an interesting problem:

Given:
(1) an arbitrary map with obstacles
(2) an arbitrary location and facing/heading
(3) current velocity, maximum rotation rate, maximum acceleration

Find:
(A) the 'smoothest' path to move between two detected obstacles. Smooth being defined as: the highest rate of speed with the least amount of total facing/heading changes

gotta do chores for now - I look forward to talking more later on
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Most silly game ever ...

Post by Tourist Trap »

leopardpm wrote: Smooth being defined as: the highest rate of speed with the least amount of total facing/heading changes
Right for all.
And thanks I'll add the acceleration rates. And boundaries.
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

this is interesting, AND, it ties in with all my research and efforts into pathfinding in general. Right now, I have been 'smoothing' my paths using the string pulling technique which removes unnecessary corners by checking line of sight between the previous and next waypoints - this works perfectly except that the resulting path is still a series of line segments - no curves, and no agent size/collision detection.

have been researching tonight about curve fitting algorithms and found quite a few, trying to sort through and find a fast one that produces optimal results everytime - also need to modify it to take into account turn radius and acceleration variables... tricky. Hmm, got to be a quick, easy way to do this....
BasicCoder2
Posts: 3906
Joined: Jan 01, 2009 7:03
Location: Australia

Re: Most silly game ever ...

Post by BasicCoder2 »

It seems to me you guys are talking a 2D physics game engine.
Polygons are probably the best way to go with such complexity. A rotated image can always overlay a polygon.
Below is a point that moves about in straight lines bouncing off obstacles and a boundary if they come too close.
An important consideration is that if an agent moves more than one pixel per cycle you may overlap or overshoot an obstacle and that requires extra computations to undo or adjust the move.

Code: Select all

'written by BasicCoder2 23rd Aug 2016
'some useful defines
Const Pi = 4 * Atn(1)
Dim Shared As Double TwoPi = 8 * Atn(1)
Dim Shared As Double RtoD = 180 / Pi   ' radians * RtoD = degrees
Dim Shared As Double DtoR = Pi / 180   ' degrees * DtoR = radians

Dim Shared As Double rAngle            ' angle of ray

Screenres 640,480,32
color rgb(0,0,0),rgb(255,255,255):cls

'=========    create a background ==================
dim shared as any ptr background
background = imagecreate(640,480,rgb(255,0,255))

'sub drawPolygons()
    dim as integer x1,y1,x2,y2,total,xc,yc,polygonCount
    polygonCount = 5

    for j as integer = 1 to polygonCount   'for each polygon
        read xc,yc
        read total,x1,y1
        for i as integer = 0 to total-1
            read x2,y2
            line background,(x1+xc,y1+yc)-(x2+xc,y2+yc),rgb(0,0,0)
            x1 = x2
            y1 = y2
        next i
        paint background,(xc,yc),rgb(100,100,255),rgb(0,0,0)
    next j
'end sub
'=======================================================

dim shared as integer WORLDX = 640
dim shared as integer WORLDY = 480


dim shared as any ptr rayPath
rayPath = imagecreate(WORLDX,WORLDY)


type AGENT
    as integer ox
    as integer oy
    as integer dx
    as integer dy
    as double  oAngle
    as double  mv
end type

dim shared as AGENT agent1
agent1.oAngle = 45  'direction angle
agent1.ox = 320
agent1.oy = 240
agent1.mv = 4


Dim Shared As Double dx,dy             ' some working variables

Dim Shared As Double w

sub drawWorld()
    screenlock
    cls
    put (0,0),background,trans    'show obstacles
    put (0,0),rayPath,trans  'show ray path
    circle (agent1.ox,agent1.oy),5,rgb(0,0,0)  'on screen not bitmap
    screenunlock
end sub


''============================================================
'' This shoots ray from observer and returns type of pixel
'' of any target hit. It also draws a ray on the ground
''============================================================
function shootRay(x1 As Integer,y1 As Integer,angle As Double) as integer
    dim as integer distance
    distance = 0
    Dim As Double dx,dy,change,aa,x,y

    dx = Cos(angle)
    dy = Sin(angle)
    y = y1
    x = x1

    If Abs(dx)>abs(dy) Then
        change = Abs(dy)/Abs(dx)
        If dx<0 Then
            aa = -1
        Else
            aa =  1
        End If
        If dy<0 Then
            change = - change
        End If
        'flag = 0
        While x>=0 And x<WORLDX And y>=0 And y<WORLDY and point(x,y,background)=rgb(255,0,255)
            x = x + aa
            y = y + change
            pset rayPath,(x,y),rgb(255,0,0)     'draw ray
            distance = distance + 1
        Wend
    Else
        change = Abs(dx)/Abs(dy)
        If dy<0 Then
            aa = -1
        Else
            aa = 1
        End If
        If dx<0 Then
            change = -change
        End If
        While x>=0 And x<WORLDX And y>=0 And y<WORLDY and point(x,y,background)=rgb(255,0,255)
            y = y + aa
            x = x + change
            pset rayPath,(x,y),rgb(255,0,0)        'draw ray
            distance = distance + 1
        Wend        
    End If
    return distance
End function

'==========   MAIN LOOP =====================
dim as integer  distance
dim as integer  min,max    'min and max distances
dim as single   rayAngle, MaxAngle , minAngle'angle of last longest distance

Do

    distance = 0
    
    drawWorld()
    
    'move agent
    'compute dx,dy
    agent1.dx = cos(agent1.oAngle * DtoR) * agent1.mv
    agent1.dy = sin(agent1.oAngle * DtoR) * agent1.mv
    
    agent1.mv = 4  'back to normal
    
    'add to position
    agent1.ox = agent1.ox + agent1.dx
    agent1.oy = agent1.oy + agent1.dy
    if agent1.oAngle > 360 then agent1.oAngle = agent1.oAngle-360
    if agent1.oAngle < 0   then agent1.oAngle = agent1.oAngle+360

    '================ 360 degree scan  ====================
    line rayPath,(0,0)-(639,479),rgb(255,0,255),bf  'clear buffer
    
    'shoot ray return distance
    rayAngle = 0  'ray angle
    max = 0
    min = 100000
    while rayAngle < 359
        distance = shootRay(agent1.ox,agent1.oy,rayAngle*DtoR)
        if distance > max then
            max = distance
            MaxAngle = rayAngle
        end if
        if distance < min then
            min = distance
            minAngle = rayAngle
        end if
        rayAngle = rayAngle + 5 'increment size depends on size of array
    wend

    'check for near collision
    if min < 10 then
        agent1.oAngle = agent1.oAngle - 180 + int(rnd(1)*45) 'maxAngle '+ int(rnd(1)*50)-25
        if agent1.oAngle > 360 then agent1.oAngle = agent1.oAngle-360
        if agent1.oAngle < 0   then agent1.oAngle = agent1.oAngle+360
        agent1.mv = 10 'big get away
    end if

    'check for boundary
    if agent1.ox < 20 or agent1.ox > 619 or agent1.oy <20 or agent1.oy>459 then
        agent1.oAngle = agent1.oAngle + 180 + int(rnd(1)*45)
        agent1.mv = 10 'big get away
    end if



    sleep 2

Loop until multikey(&h01)

DATA  138,108
DATA  4
DATA -60,-33,10,-56,61,-6,-51,56,-60,-33
DATA  463,342
DATA  6
DATA  36,-74,96,16,49,75,-61,71,-95,19,-60,-71,36,-74
DATA  383,109
DATA  10
DATA -30,-67,-57,-46,-86,1,-74,46,-31,71,26,78,77,45,86,-4,71,-58,36,-78,-30,-67
DATA  172,323
DATA  10
DATA -110,-81,124,-81,121,-25,105,17,67,51,24,76,-39,81,-86,70,-111,31,-123,-22,-110,-81
DATA  564,133
DATA  16
DATA -22,-83,-44,-75,-50,-57,-47,-30,-35,-21,-31,2,-41,32,-46,60,-15,81,20,84,50,57,49,17,36,-10,17,-36,19,-62,5,-84,-22,-83
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

I don't know about this being a physics issue or engine, seems just like a basic steering problem with some additional variables (turning speed and acceleration).... but perhaps you are right - when I hear 'physics engine', I think of gravity, mass, collision/bounce, object interaction, force, etc...

Here is what I have come up with so far, seems pretty simple and fast and should produce the optimal curved + straight line path....

Image
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

BasicCoder2 wrote: Below is a point that moves about in straight lines bouncing off obstacles and a boundary if they come too close.
it don't bounce right..... but I luv it anyways! - how fun is THAT!
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

In my search to code my idea, I needed to figure out how to draw the arc piece and discovered two things:

(1) not only is there a Bresenham's line and circle algorithm, but also a version to draw an arc... yay!

(2) I found FREEBASIC source code in WikiPedia! Yay! We made the big time!

here is the circle FB code from wikipedia:

Code: Select all

' version 06-07-2015
' compile with: fbc -s console
' OR compile with: fbc -s gui
 
' Variant with Integer-Based Arithmetic from Wikipedia page: Midpoint circle algorithm
Sub circle_(x0 As Integer, y0 As Integer , radius As Integer, Col As Integer)
 
    Dim As Integer x = radius
    Dim As Integer y
    Dim As Integer decisionOver2 = 1 - x ' Decision criterion divided by 2 evaluated at x=r, y=0
 
     While(x >= y)
        PSet(x0 + x, y0 + y), col
        PSet(x0 - x, y0 + y), col
        PSet(x0 + x, y0 - y), col
        PSet(x0 - x, y0 - y), col
        PSet(x0 + y, y0 + x), col
        PSet(x0 - y, y0 + x), col
        PSet(x0 + y, y0 - x), col
        PSet(x0 - y, y0 - x), col
        y = y + 1
        If decisionOver2 <= 0 Then
            decisionOver2 += y * 2 + 1 ' Change in decision criterion for y -> y+1
        Else
            x = x - 1
            decisionOver2 += (y - x) * 2 + 1  '  Change for y -> y+1, x -> x-1
        End If
     Wend
 
End Sub
 
' ------=< MAIN >=------
ScreenRes 800, 800, 32
Dim As Integer w, h, depth
Randomize Timer
 
ScreenInfo w, h
 
For i As Integer = 0 To 50
    circle_(Rnd * w,  Rnd * h , Rnd * i * 4 , Int(Rnd * &hFFFFFF))
Next
 
'save screen to BMP file    
Bsave "Name.BMP", 0   
 
' empty keyboard buffer
While InKey <> "" : Wend
Print : Print "hit any key to end program"
Sleep
End
and I LOVE this page!
http://members.chello.at/~easyfilter/bresenham.html
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Most silly game ever ...

Post by Tourist Trap »

BasicCoder2 wrote: An important consideration is that if an agent moves more than one pixel per cycle you may overlap or overshoot an obstacle and that requires extra computations to undo or adjust the move.
The collision has in my opinion to be always checked with the efficient algorithm that are avaiable (line sweeping). Trajectory setting is in another hand the problem of the robot. That doesn't mean that it can not fail, if it fail this is the main program that will report the collision. It's the way I see that in any case.
Nice demo by the way. If you could plug an "analyser" of the detected obstacle, your droid could make its path in this world ;-)
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Most silly game ever ...

Post by Tourist Trap »

leopardpm wrote:(2) I found FREEBASIC source code in WikiPedia!
I have been looking for this for hours, thanks (I still don't see why it should differ of 4 pixel from the classic Bresenham, still have to test). Becareful this seems to do a BSAVE in your snippet. I think nobody needs to save any image here, what for?
leopardpm wrote:Here is what I have come up with so far, seems pretty simple and fast and should produce the optimal curved + straight line path....
Thanks for the schemes, that helps clarifying the mind. I think that all of this is classic enough, that's physics but no more than kinematics that generally has very well defined solutions and tools.

For the moment I'm still trying to optimize my line sweeping algorithm. I'll be back for this when this is done. Sweeping is a delicate lovely thing that requires attention ;-)
leopardpm wrote:it would be easier to scan and determine edges/corners if everything was polygons... but if a grid, then will have to make your own polygons from the scan points (which do not have to be extremely 'fine' - can probably get away with 1-5 degrees apart, depending on the size of everything, etc)...
I've from my point of view made this less general. The droid is only looking from freepaths, he doesn't need (here) to know about the shape of what he meets on his way. It's only one kind of sensor. We can think of more. I'm also planning a z-map analysis that seems more able to deal with general shape of the obstacle as far as I see it.
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

I have been looking for this for hours, thanks (I still don't see why it should differ of 4 pixel from the classic Bresenham, still have to test). Becareful this seems to do a BSAVE in your snippet. I think nobody needs to save any image here, what for?
Bresenham Circle can be done in 2, 4, 8, 16, 32, etc points... but 8 is pretty optimal for speed

Yeah, I noticed the weird BSAVE, didn't seem to hurt anything but should probably be taken out

For the moment I'm still trying to optimize my line sweeping algorithm. I'll be back for this when this is done. Sweeping is a delicate lovely thing that requires attention ;-)
how is your world represented, as a grid or as actual polygonal objects? No real need to sweep with polygons, as mentioned before. If a grid, then how are you optimizing it? are you looking for the corners (waypoints)?


Note on my post 3 posts back (with the picture)..

The maximum speed through two waypoints is found by:

(1) Determine the minimum distance between the two objects

(2) divide it by 2

this number represents the maximum turning radius, from which can be figured out the speed which corresponds to that radius.... easy peezy pie!


I think this is the complete theory now:

(1) Given two obstacles, determine their corners (waypoints) and the minimum distance between the objects

(2) figure out the Max Speed and Max Turning Radius (above) (MTR)

(3) from the start point to the first waypoint, find the line tangent to the circle with a center of waypoint and MTR, remember this tangent Point as T1

(4) from this first waypoint to the next waypoint, determine the line tangent to both MTR circles, this gives two points, one on each circle T2 & T3

(5) Now you have: lineSegment from Start to T1, an arc for the first circle, from T1 to T2, and line segment from T2 to T3

(6) Now repeat through the waypoints, determining the next tangent points....
Last edited by leopardpm on Aug 24, 2016 9:11, edited 1 time in total.
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

Tourist Trap wrote:I've from my point of view made this less general. The droid is only looking from freepaths, he doesn't need (here) to know about the shape of what he meets on his way. It's only one kind of sensor. We can think of more. I'm also planning a z-map analysis that seems more able to deal with general shape of the obstacle as far as I see it.
don't know what "z-map analysis" is...

to figure out your maximum speed in going between two objects, your droid needs to be able to quickly figure out the minimal distance between the two objects, which means you need to know all of the corners of each objects' shape... or else you will be computing distances from each and every pixel (grid point) in one object to the other, which would be turtle slow, I think....
Tourist Trap
Posts: 2958
Joined: Jun 02, 2015 16:24

Re: Most silly game ever ...

Post by Tourist Trap »

leopardpm wrote:don't know what "z-map analysis" is...
Z-map is better rendered by grey-level map. You must have seen this for robots like those who walk on moon. That renders the distance between a screen and the objects. That's a kind of 3D for robots ;-)
This also could be a lot of fun. If the grey gradient is smooth that's the side of a building, it changes soudainly, it's a corner. And probably other deductions may be done with this. If it's dark it's deep, if it's clear it's close. Very intuitive.
leopardpm wrote:(1) Given two obstacles, determine their corners (waypoints) and the minimum distance between the objects
(2) figure out the Max Speed and Max Turning Radius (above) (MTR)
(3) from the start point to the first waypoint, find the line tangent to the circle with a center of waypoint and MTR, remember this tangent Point as T1
(4) from this first waypoint to the next waypoint, determine the line tangent to both MTR circles, this gives two points, one on each circle T2 & T3
(5) Now you have: lineSegment from Start to T1, an arc for the first circle, from T1 to T2, and line segment from T2 to T3
(6) Now repeat through the waypoints, determining the next tangent points....
I agree with all of this. Maybe a simplified code could illustrate this rather than intergrating in the current implementation. I think I need a second version for everything with a wider view.
Last edited by Tourist Trap on Aug 24, 2016 9:24, edited 1 time in total.
leopardpm
Posts: 1795
Joined: Feb 28, 2009 20:58

Re: Most silly game ever ...

Post by leopardpm »

I just thought of something, assuming your Droid cannot 'know' instantly the complete shape of an object (and all of its corners...), it can determine the point on each of the two objects that it can 'see' - even though this isn't a complete picture, it can determine the max speed up to that first waypoint, and from there it can see at least the next waypoint and adjust its speed as necessary... I think.... would need to test this.... so it would basically ip up to that first tangent point, then slow down (if needed)... nope this won't work.... but provides an estimate....
Z-map is better rendered by grey-level map. You must have seen this for robots like those who walk on moon. That renders the distance between a screen and the objects. That's a kind of 3D for robots ;-)
like a height map, but distance instead of height? so each point it detects is darker/lighter depending upon distance?
Post Reply