# Re: (TFT) Online Melee

• To: tft@brainiac.com
• Subject: Re: (TFT) Online Melee
• From: Lloyd Weber <laweber3@yahoo.com>
• Date: Wed, 18 Oct 2006 19:52:31 -0700 (PDT)
• Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type; b=p+WNpL5EEwl//KuU2hy4wNJtNj4he7U9x9l0Cm94G0/1jnZ5oXPyQ/UelQmM3n25m4y5xNlMJ4SSyJxplv4PohFfr2HnK15pbveybmoRCGNN6FP7zXTaYMIOjZtnjAIs2HhK6r8F75nNGMT7BvuIcOWWI779CE/WaM0T8BzqCzQ= ;

```I am also trying for a general hex board solution, on top of which sits a game
such as Melee Arena, and later on, other Melee-based games. The hex board I've
developed would allow any size or shape of map to be generated, whether it is
rectangular like the arena, or round or with passage ways, etc, so I'm looking
forward to extending the game beyond Melee Arena after all the movement and
combat details are worked out and that game works.

I got a LOS routine
working yesterday. I tried two algorithms:
1) draw losLine from center of
hex1 to center of hex2, test each hex - if losLine intersects the line between
two vertices of a hex then that hex is in LOS.
2) draw losLine from center
of hex1 to center of hex2, test each hex - if center of hex is closer than
hexWidth / 2 pixels from line then that hex is in LOS.

I thought method 1
would be more correct, but it has the downside of including hexes where the
losLine travels exactly along the edge, which we don't want - I added a test
to check if both endpoints of the hex side were on the line but that didn't
work - this algorithm just wasn't quite working even though it seems like it
should. Algorithm 2 works quite well, but one possible downside is that
occasionally the very corner of a hex intersects the losLine but still the
center is more than half the hex width away from the losLine, such that, even
though it visually I can see that the line intersects, the algorithm doesn't
include that hex. I decided this was ok because distance from the center is
more realistic than worrying about the very corners of hexes intersecting, at
least concerning whether an intervening character might be hit by a thrown
weapon. Also, testing every hex probably isn't the most efficient way, but its
quite fast for smaller maps. For a very large map, if
the algorithm turned out to be too slow, I could probably modify it to only
test hexes nearer to the line.

So, now I can calculate distance in hexes, los
intersections, neighbors, and megahex groupings. I still need to write an
algorithm for finding the set of hexes in front of a character, i.e. the hexes
that a ranged weapon can target. This set of hexes will also be used, in
combination with an extended losLine, to find the hexes in LOS beyond the
target hex incase the target is missed and the weapon/arrow continues on.
Lloyd

----- Original Message ----
From: Christopher Fuhrman
<fuhrman8or@yahoo.com>
To: tft@brainiac.com
Sent: Wednesday, October 18, 2006
11:18:54 AM
Subject: Re: (TFT) Online Melee

--- Lloyd Weber
<laweber3@yahoo.com> wrote:

> There are good ideas in there for line of
sight. I've done my hexes
> differently though, and I'm hoping to be able to
continue to use
> Java's graphics 2D package for calculating line/hex
intersections.
> If Irun into
> trouble with it then I'll probably rewrite
the whole hex board
> part, but for
> now I think its ok, and even seems
pretty easy to work with.
>
> Thanks again!

For the record, I found (once
again) the site by Mark Butler that has
another way of line-of-sight handling
of hexagon maps (this time in
Javascript) - it was in my older browser's
bookmarks so many years
(and PCs) ago it seems, but I recently found it again

http://www.webwargaming.com/combat/

An example of the
JavaScript that is used, can be seen (at least with
my Firefox browser) here:
http://www.webwargaming.com/combat/los.js

The combat page loads in a lot of
.js files, but I haven't seen
anywhere where these programs are documented
which aren't too bad, and the rules that are
documented) or
distributed as a .zip file or something more centralized.

One
should realize that Mark Butler's hexagon mapping logic is based
on "hex
parts" (http://www.webwargaming.com/hexpart/hexpart.html),
idea. It's yet another way to skin a cat.

I'm trying to develop a Java
version of the stuff from Clark
Verbrugge's line-of-sight algorithms, but
there are some cases where
the algorithm as-is fails and I'm trying to work
out the bugs. The
whole "flattened" hex, non-orthogonal axes strategy is
putting my
brain in a pretzel.

Ideally, I'd like to provide a
HexCoordinates.java class that offers
functions for all of the tricky stuff,
including distance, paths,
different variants of LOS, etc. I'm aiming for a
good design that
would facilitate the building of other engines.
__________________________________________________
Do You Yahoo!?
Tired of
spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
=====
Post to the entire list by writing to tft@brainiac.com.
Unsubscribe by
mailing to majordomo@brainiac.com with the message body
"unsubscribe tft"
=====
Post to the entire list by writing to tft@brainiac.com.
Unsubscribe by mailing to majordomo@brainiac.com with the message body
"unsubscribe tft"

```