ToME: the Tales of Maj'Eyal

In Maj'Eyal, lines sort of avoid obstacles to some extent when you're using projectile/beam spells. Is it a feature of Maj'Eyal or of the TE4 Engine?

I'd like to know where to find the code for this feature or the broad logic behind it. It would be really helpful.

The Selfish Gene wrote:In Maj'Eyal, lines sort of avoid obstacles to some extent

Only sort of?! It doesn't avoid obstacles that the user can't see or doesn't know about, but it should do a good job otherwise! Heh, although it may try to shoot through tiles such as friendly units. Do you have examples where this doesn't perform as expected?

The Selfish Gene wrote:Is it a feature of Maj'Eyal or of the TE4 Engine?

The engine. In C.

The Selfish Gene wrote:I'd like to know where to find the code for this feature or the broad logic behind it. It would be really helpful.

Heh, I wouldn't assume the code will be helpful. It is not for the feint of heart. Do you want to use this feature, understand it, reproduce the behavior elsewhere, or what?

The bulk of the code is here:
http://git.net-core.org/tome/t-engine4/ ... /fov/fov.c

The following code is used to determine the line start and end positions, angle, etc. There is different code that is run, for example, when a projectile is actually flying along the specified path.

Consider yourself warned, but I will try to step you through the relevant parts. Let me know if you have any questions. I wrote this code (sorry gentle readers!).

This block uses functions defined by macros and creates the line in a given octant. It is a reasonable place to start:
http://git.net-core.org/tome/t-engine4/ ... L2543-2578

The functions are defined by the macros here:
http://git.net-core.org/tome/t-engine4/ ... L2207-2214

This is the main macro:
http://git.net-core.org/tome/t-engine4/ ... ov.c#L2011

The code that runs when the line finishes is here. It has special logic if the line is blocked or not:
http://git.net-core.org/tome/t-engine4/ ... ov.c#L1877

The macros use this macro, which determines the optimal boundary of vision:
http://git.net-core.org/tome/t-engine4/ ... fov.c#L598

Hmm, the definition of the fov line struct may also be useful:
http://git.net-core.org/tome/t-engine4/ ... h#L133-173

There are similar functions/macros that do this for hexagonal maps too.

Good luck!

Also, if you want to know more about the FOV algorithm used in ToME, see here:
http://forums.te4.org/viewtopic.php?f=45&t=35232

Creating "smart lines" for the basic recursive shadowcasting algorithm is much simpler. Perhaps you should start here:
http://git.net-core.org/tome/t-engine4/ ... L2579-2722

I didn't mean "sort of" as criticism. I meant it stays on plausible sight lines and only avoid walls. (as it should!)

Thank you so much for the reply. I did not expect to get so much information. It's also kind to offer to help. I'll study what you gave me here tomorrow and see if I can understand some of it.

I'd like to reproduce it, but I also want to understand it. I could maybe get something similar by using smooth pathfinding to a target while using the source's current FOV minus walls as walkable tiles. However, I'm assuming it's maybe not the best way to do it.

I've played Maj'Eyal quite a bit, and didn't notice how amazing the feature is until I saw it missing in action. lol

tiger_eye wrote:

The Selfish Gene wrote:In Maj'Eyal, lines sort of avoid obstacles to some extent

Only sort of?! It doesn't avoid obstacles that the user can't see or doesn't know about, but it should do a good job otherwise! Heh, although it may try to shoot through tiles such as friendly units. Do you have examples where this doesn't perform as expected?

Obstacles the user can't see and doesn't know about aren't the same thing. It doesn't handle dark corridors intelligently. There's a valid path in which there are known to be no obstacles (because otherwise the target wouldn't be visible) adjacent to a path with obstacles that the player knows are there because corridors are always one tile wide. The "smart" targeting cuts through unknown tiles that are obviously obstructed but not actually seen rather than taking the legal path down tiles that are known to be unobstructed. Assuming all never seen tiles are obstructed might work better if seeing through a tile with infravision marked it as clear. Or maybe make infravision see any walls that are partially occluding a visible monster. Something like that.