GameMaker Calculating Fov from a ds_grid

S

Snayff

Guest
Afternoon all,

I have my world info stored in a ds_grid as a bitmask and my entities are mapped on to another ds_grid. My intention is to track what tiles are currently visible by recalculating the field of view (FOV) whenever the player ends a turn in a different space to where they started.

My challenge is that I am not sure how to work out the FOV. If I were using objects I would look at line collisions or ray casting but as it is just info on a grid I am not sure where to start.

I've had a look around online and I think there are lots of resources describing how to check for line of sight or field of view, so once I know how to interact with/interpret the data from the grid I think I might be ok.

Any help would be appreciated.
Snayff
 
S

Sinaz20

Guest
Presuming that there is a visual component to this game, you could still perform the FOV checks in the actual room with the actual game objects and functions that react to them, then transpose the results back into the grids.
 
S

Sinaz20

Guest
Another, similar solution is to make graphically small proxy objects and build a scale model of the data in the room, on its own layer. You can leave these objects invisible and even deactivated until you need to perform any checks. Wake them up (if deactivated), perform the fov solution, and transpose the results back to the grid.

Like, these proxy objects could be 2x2 pixel squares occupying the space at 0,0 in the game world and basically mirroring the grids.

You could also roll your own raycasting script designed purely for grids... but in these situations, I prefer extracting the results from systems already existing in the engine and just tackling the problem from a different point of view.

[edit]For your reading pleasure:
https://rosettacode.org/wiki/Ray-casting_algorithm
 
S

Snayff

Guest
Another, similar solution is to ...
Thanks for coming back to me.

The player and NPC's are objects but not the walls or anything else stored in the world ds_grid. I'd rather not have to use objects in place of the sprites i am using now but if there isn't really an alternative then I think I will have to!

I'll read the article you linked and maybe I can find some inspiration. I hoped there might be a way to apply the same idea of ray casting but to the grid data, rather than objects.
 
Last edited by a moderator:
S

Sinaz20

Guest
Always keep in mind you can process scenes at runtime and just make that processing time part of the load time. People will forgive a minor hiccup at that moment.

But if your issue is managing building the room twice, once with the actual sprite assets, and then again with proxy objects or whatever, you write a script to generate this stuff from the easiest phase of the setup that you care to do manually. So a script to scan through all the sprites and automatically create instances of low overhead objects is a viable solution.

I know it often seems like it is imperative to use as few objects as possible, but really, you have a lot of room on a modern computer for graphics and processes... so long as you are thrifty in your code and logic. Think about things like, "do I need wall objects filling up the voids between actual walls?" Probably not.

Objects and the existing API are there to fill the solution you are trying to re-engineer. I don't know the specifics of your project, but you probably have more than enough overhead to spare doing this with actual room objects.
 
S

Snayff

Guest
Thanks @Sinaz20 , lots of food for thought. Because the field of view will change whenever the player moves I will need to frequently create and dismiss those objects, but doing so should allow use of the usual line of sight calculations. I am definitely less worried about the processing required than I am about my ability to do that in a way that won't be inherently flawed. ;)
 
Top