GFA BASIC Collision detection

[Fletch]

I've started messing about with making a simple Rogue-like game in GFA BASIC. I want to create a character that navigates about the rooms and when it reaches a wall or an object the path is blocked.

 

I've been combing the GFA manual, but haven't found anything conclusive on which commands I should be using to help.

 

Any suggestions?

 

Thanks!

 

-Pete

 

 

[Fletch]

It looks like I can use the POINT command. That returns the color value at a specific X,Y. I think I can make that work for simple detection.

[ggn]

Just a suggestion: DIM a 2D array that will keep your world and use that instead of reading pixels from screen.For example:

 

dim world|(100,100)

arrayfill world|(),0

 

 

Now our world array is a 100x100 table that contains 0. Let's assume that 0=nothing in our world

 

 

for i=1 to 100

world|(i,1)=1

world|(1,i)=1

world|(i,100)=1

world|(100,i)=1

next i

 

Now our world has the value 1 at its edges. Let's assume that 1=walls.

 

for i=1 to 500

world|(rand(100),rand(100)=1

next i

 

That put some random walls in our world. Nothing fancy but it'll do the trick.

 

world|(10,10)=2

 

Let's assume that 2=your player.

 

 

Now, you can use that array to modify your world and render it. You can keep your player's x,y coords into 2 variables (player_x,player_y) and when you move him just write 0 to the old position and 2 to the new. There are plenty of ways to render the array to screen. One of the easiest one is

 

for y=1 to 100

for x=1 to 100

color world|(x,y)

plot x,y

next x

next y

 

Of course this is really slow and just represents each block in the world with one pixel! You can use a lot of different methods like drawing (say) 16x16 boxes instead of a single pixel, or replace them with sprites - which means that you don't have to render the full world in one screen. In any case, the core principle remains the same: use one array to keep the status of your world and use it for everything.

 

Hope this helps!

[Fletch]

Thanks for the tips! I am very new to GFA BASIC and not much of a programmer, so I appreciate all of the advice I can get! I'm sure I'll be back with more questions.

 

-Pete

[danwinslow]

Yep, that's one way to do it. Plus you can encode other information in the map, too. This works great for tile based games.

However, If you are trying to collision detect on a pixel-by-pixel basis for like missiles and ships flying around over a space background, then you'll need almost as much space in your map as you do for the screen, so you might as well just read the pixel color. You'll have to carefully allocate colors though, so you can know what you're 'running into'.

[ggn]

This works great for tile based games.

 

 

I've started messing about with making a simple Rogue-like game in GFA BASIC. I want to create a character that navigates about the rooms and when it reaches a wall or an object the path is blocked.

 

Just replying questions as I see them - let's not try to complicate things!

[Fletch]

Thank you Ggn and Dan. I realize there is always more than one way of accomplishing the same goal. I didn't get a chance to mess around with it last night, but I hope to this weekend.

 

-Pete

[danwinslow]

In 1985 I wrote a kind of gauntlet-like clone in GFA basic on my ST (except it had elements of telengard and various other RPG style games) call Hero III : Vapids Keep. (No relation to H.E.R.O. at all). I compiled it using the GFA compiler. I even got it 'published' and a run of disks and manuals made, but the so-called 'publisher' pretty much immediately failed and went back to his mom's basement. It was fun though and I learned a lot, Glad to help with advice as you go along, feel free to ask.

[simonsunnyboy]

Reading pixels with GFABASIC will work but my experience with this is not so good. I would combine a tiled background with the technique by ggn with moving sprites above.
A spritebased pixel coordinate can then be calculated to see what tile is below.

Sprite collision detection is best done with comparing their respective coordinates and size for intersection. I can recommend using the ABS() function there.

For the first true game ever, a pure tile based game might be hard enough to complete.

[MikeFulton]

Looking at pixels isn't really the best way to do it.

 

Gnn's method works ok in many cases, but it's really sort of a brute force approach that might not scale well to larger sizes.

 

If you don't mind a more sophisticated method, my suggestion would be to create a list of rectangles that describe the things you can collide with. Also create one for the character. Then what you do is check the character's bounding box against the rectangles in the list. You can arrange the list so that you can find out quickly if a collision isn't possible. For example, if you have your list divided into screen quadrants, you can skip the rectangles that are in completely different ones from the character.

 

You can also use several overlapping rectangles to fine-tune the accuracy. For example, you could have one overall bounding box for the entire character, and smaller ones for individual sections. Then if you find that you're intersecting the overall rectangle, you check the smaller ones. But if you're not intersecting the overall, you don't have to worry about the smaller ones.

[danwinslow]

Mike's suggestion is the ultimate way to go. It's faster and at least as accurate, and usually more. It's complex to set up and understand for a beginner though.