Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

hihp

hex-line calculating routine?

This topic is 6681 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone, I''m new at this stuff, and I''d like to code a hex engine - specifically to write a game based on the BattleTech universe. Now, what I need is a routine that tells me which hex fields are touched when I draw a line from the center of a hex to the center of another. Important is that the hexes are drawn with a horizontal line being the top line, and I must be telled by this routine, too, whether the line drawn touches two hexes at the same time at the same position, i.e. wanders directly over the side of a hex so that one cannot tell which of both has been touched.

Share this post


Link to post
Share on other sites
Advertisement
there are a number of ways for you to get the effect that you desire. (its funny how this is an easy thing to do with a straight rule on a piece of hex paper, but with a computer, its very computation intensive)

here''s one possibility. it would not be suitable if your game is realtime, but it would be OK if you''re doing a turn-based thing.

you may want to look up some of the HRGN functions in MSDN, especially CreatePolygonRegion.

using that function, you can make a number of regions that comprise a single tile in the map.

now, when firing, you first determine the angle you are firing at, then you create a new polygon region, and to do so, you make the firing path slightly wider than a single line. (you can make the path 5 pixels or something, so that you''d have a polygon that you can make a region from)

now, you need a recursive function to calculate what areas are hit by the firing path.

the first part of the function checks to see if that hex has already been check. if it has, it exits the function

next, it marks the hex as checked

now, it determines if the firing area intersects with the region that makes up the tile, and marks it true or false

the way it checks to see if the firing region intersects with the tile is by using IntersectRegion

next, for each adjacent tile, it sends the data for that tile to the same function.

with a function like this,
(A) each tile is only checked once
(B) checks for tiles that do not have an intersection with the firing area are minimized
(C) the "hitting two tiles at once" problem is solved, because our firing area is wider than a single line.
(D) there isnt a whole lot of math involved
(E) it''s not the fastest
(F) about 3 times the number of tiles are checked than are actually hit
(G) its the first idea that came to me

tonight, i''m going to do a small demo of this method, to check its viability. (its the kind of thing that should be in my book, so i should probably include it if its a good algorithm)

Share this post


Link to post
Share on other sites
Sorry that I didn''t reply for quite a long time, but univesity kept me from continuing my current project.

The code you sent me looks quite promising, TANSTAAFL, but it is not exactly what I had in mind because of what you see as an advantage of your code, the "two hexex hit at once" problem.

The prob is that I want to write an "as exactly as possible" adaption of the battleTech rules. And that requires the whenever the line of sight calculated for a shot passes to adjacent hexes exactly on the border, the defender (the target) can choose which of these hexes belongs to the los (with the effect that the terrain on that hex counts to the malus of the attacker''s hit probability). You see, I am going to make compromise to the BattleTech rules in any case as I will automize the process of the opponent choosing the hex as I will always count the hex with the higher shot probability modificator. I cannot simplfy this too much because the difference between open area or wood can make a player''s day...

Share this post


Link to post
Share on other sites
This problem got posted to his IsoHex book mailing list. I made a modification of his demo to handle the situations in a manner more true to the LOS rules. The algorithm is a extremely hacked version of Bresenham''s Line algorithm.

Follows is a link to the attachment on the mailing list.
http://pix.egroups.com/attach/506292/44/gs-50=62=506292/10-1-10-88/application=zip/HEXSIGHT.ZIP

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!