• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
Azaral

2D Raycasting

7 posts in this topic

I'm working on the code design/layout/architecture/whatever for a game I'm making. I want to implement line of sight so that things the player can't see won't be drawn on the screen. I found an example that is pretty much what I want. It uses ray casting and I haven't been able to find much on the subject outside of using it in 3D to render a scene.

I have some ideas on the matter that I'll share and maybe I'm on the right path already. If anyone could help me out by explaining it or showing me a good tutorial or some such I would appreciate it.

 

My world is pretty empty as far as most games go. Essentially, the player is flying around a ship in space and there are asteroid type objects in space. These are the only objects that block line of sight so far, everything else can be seen through.

 

An asteroid is a simple polygon consisting of points and the lines those points make.

 

My first thought, which I'm sure is terrible, was iterating along a vector in a loop and seeing what it hit. I won't be doing that lol.

 

My second thought a few seconds later was to test against the points and lines of the asteroid objects. I would determine open fields of view by testing the points of the asteroid objects and seeing where they intercepted lines of other asteroids. I would create a line function by going from the player's origin of view, the center of the screen, and going to the point in question. Then, using the formula for that line, test it against lines of asteroid objects (after running some yet to be determined algorithm to occlude asteroids that aren't even in the direction the ray is going). This will find the point of intersection between the ray and the line being tested again. I would then take the x value of the point and put it into the formula for the line being tested. If the resulting y value is between the y values of each endpoint of the line segment, then I would know that the ray is intersecting that line and that line is going to block line of sight all the way from one end point to the other end point. This would give me fields to test and see if enemies are within and if so draw them.

 

I also plan to use this same algorithm for AI navigation. Each area is created procedural during the game, so using navigation nodes is out of the question. I would use this same algorithm for determining areas that are safe to fly in if the AI were to travel in a straight line and whether or not the AI could see the player so they could shoot at them.

 

Is this a smart way to go about casting the rays? I've got a number of ideas for simplifying the algorithm as a whole (for instance checking if there is even an enemy on the screen to see if it should even determine player LOS and what not), but its the actual testing of the rays themselves and seeing what they hit that I want to make sure I'm on the right track for. It seems like it would be pretty darn fast to me, but my inexperience might hide something from me.

0

Share this post


Link to post
Share on other sites
Sounds like you are talking about calculating a visibility polygon which is a good way to do fog of war type things.
0

Share this post


Link to post
Share on other sites

How many kinds of asteroids will there be? How close are they to being circular? Can you approximate them as circles?

 

Will the asteroids move by translation or by translation and rotation?

Edited by jwezorek
0

Share this post


Link to post
Share on other sites

At first it looked like you want to do a 2D game, but later it appeared to me that it is a 3D game with Asteroids - sort-of an Privateer/X-Com-like ?

 

In that case it might prove beneficial to look into Octrees, since you can reuse the nodes for multiple processes in the game, not just Frustum Culling.

 

I would also propose using the Sphere bounding boxes - the calculations are almost nonexistant and those few corner cases are not important from the gameplay/engine perspective anyway - even if the sphere itself partially intersects the frustum (and mesh not), the gfx card will discard processing those tris pretty early in the gfx pipeline anyway (and way, way faster than you can do on CPU anyway).

0

Share this post


Link to post
Share on other sites

I want to implement line of sight so that things the player can't see won't be drawn on the screen.

 

for fog of war in a 2d game?

 

or for occlusion culling, collision avoidance, etc, in a 3d game?

 

they are somewhat different things.

 

2d fog of war involves los/lof (line-of-sight/line-of-fine) calculations.

 

occlusion culling is a method to cull distant objects which are behind a large object nearby (such as a building), when drawing 3d scenes.

 

for targeting and navigation in a 3d game where you don't fly, you can usually just use 2d targeting and navigation. so your question of who can see what and who for purposes of targeting and collision avoidance reverts back to 2d lof/lof calculations, and 2d obstacle detection/pathfinding, etc.

 

2d los/lof is probably done fastest using raycasting, and bressingham's line drawing algo, which is essentially iterating your vector: 

 

"My first thought, which I'm sure is terrible, was iterating along a vector in a loop and seeing what it hit. I won't be doing that lol."

 

ironic, eh? great minds think alike.

0

Share this post


Link to post
Share on other sites

The game is 2D top down. The asteroids can be of any shape. It's not for occlusion for rendering purposes for performance, but more fog of war. It is also going to be used for navigation for AI and targeting for AI to determine if they should/can shoot at the player.

0

Share this post


Link to post
Share on other sites

hi there

I am working on similar game and im allready made such effect on explosions

sea algorithm demo on

http://serumas.gamedev.lt/index.php?id=visibility&sid=

and game video and demo binary on

http://serumas.gamedev.lt/index.php?id=survival1&sid=

algorithm is sweep and prune style, not yet optimized greatly but it works

I could share it. it on c++.

 

But for targetting I think that would be to much calculations and in your case I would do collision brouadphase routine.

Or angle sweap and prune.

Edited by serumas
0

Share this post


Link to post
Share on other sites

The game is 2D top down. The asteroids can be of any shape. It's not for occlusion for rendering purposes for performance, but more fog of war. It is also going to be used for navigation for AI and targeting for AI to determine if they should/can shoot at the player.

 

So if I were you I'd actually read the literature on 2D ray casting i.e. use Google...

 

But off the top of my head if you can't approximate with circles I think the next best thing would be to use the convex hull of each polygon for ray-casting rather than the polygon itself. I believe that this would not be an approximation as far as whether or not things behind the asteroid are visible goes; further, for each asteroid type until its shape changes you only need to compute the convex hull once.

Edited by jwezorek
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0