Primary tabs

Comments by User

Saturday, November 26, 2022 - 18:23

While it's out of date now, the original demo that used Flare is still available in web-only form here:

But definitely check out the commercial version. It's much improved since the demo.

Sunday, May 15, 2022 - 01:56

Not possible. For us, it would just slow down gameplay in a way that we don't want. But I can see why you might want this feature for a slower paced game/mod.

Saturday, May 14, 2022 - 13:04

Should be possible. You could use the existing circular threat range, but then add an angle to define the size of the cone within that circle. To see if the player is in the enemy's cone, you would use Utils::calcTheta() to get the polar coordinates of the enemy looking straight ahead and at the player. If the absolute value of the difference between these angles is less than the cone angle divided by 2, the player will be in the cone.

Saturday, May 14, 2022 - 03:57

Yes, threat range is a circle. There's line of sight, but it's only used in determining if a certain attack can be executed (i.e. don't shoot a projectile if the player is behind a wall).

Saturday, May 14, 2022 - 02:30

Flare has exactly the collision type you describe. We use it for half-height objects/walls, as well as for pits/water. If you open the flare-game maps in Tiled, these are blue in the collision layer. The red tiles are the other collision type, which represent an all-blocking wall. So in my last comment, the cover tiles would start as blue and be changed to red upon enter the cover state.

As for affecting enemy threat range, the player has a 'stealth' stat which can reduce the range at which enemies will see the player. At 100%, enemies can't see the player at all (we use this for the "DEV Boots" developer-only item in flare-game).

Saturday, May 14, 2022 - 00:45

That is true.

Another approach I thought of is to have an event use 'mapmod' to change the collision tiles. I can't think of how to trigger the event itself when in the cover state. I think there would need to be a way to trigger an event if the player was under a specific status effect. So that's where some new engine code may be needed.

Friday, May 13, 2022 - 22:07

Slower gameplay should work just as well in Flare. I would definitely like to see something like that, since just about every Flare mod to this point has had fast/twitch combat.

Friday, May 13, 2022 - 14:13

I don't think this is really possible as you fully describe. This method might be close, but it has some flaws:

  1. Where cover is possible, place a constantly activating power that applies a status effect to the player. This status would basically define if the player was in cover or not. The duration should be short so that it goes away after the player leaves cover.
  2. The player's "crouch" power would only be enabled if the cover status effect was active. The crouch power would be a "block" type of power, so that you could hold the button to stay in the crouch state.
  3. When in the crouch state, a passive effect could be applied. There'd be no way to make only ranged attacks miss, so the closest solution is to buff the avoidance stat, causing all incoming attacks to miss.
Wednesday, April 27, 2022 - 17:11

I don't think it would be possible to do that correctly with our 2D animation system.

If we let the run animation finish, the time it takes would vary based on where in the run cycle the player is. This would make for very inconsistent gameplay.

Since D2 Ressurected is 3D, it's possible to blend the skeletal animations no matter where in the run cycle the player is. So the transistion animation will always take a predictable amount of time to complete.

If you look at the original D2, you'll notice that its 2D animations behave more like Flare's do.

For the record, I prefer the old-school "instant-response" feeling that the lack of transitional animations gives. So I wouldn't have much motivation to pursue adding them.

Tuesday, April 26, 2022 - 23:51

I just pushed a commit that should fix that behavior:

It works by creating two "deadzones" around the player: one while moving and one while stationary. The defaults I picked feel good to me, but you can try playing with the "mouse_move_deadzone" property in engine/misc.txt if you feel it's not quite right.