Opinions on luckytime

[InsomniacPro]

So, I would like some opinions on how I should handle luckytime.
For example, I can either enumerate through players within a screen, and check for distance and check for llucky time. If a player is within range for luckytime, they start luckabsorb.

Now option B tht I have. When a player starts luckytime, its in a 7x7 grid. Now the tiles within that 7x7 grid, get an attribute declaring them luckytime tiles, a blessed tile if you will. When player is standing still on a blessed tile, they start gaining luckytime.

Which of these would be the smarter more efficient route. Or if you have another, better way, I would love to hear.

[KraHen]

Enumerate through players on the screen, it`s enough. Even if there will be 2k players on your screen only (which won`t), it still won`t be slow.

[Wolfy.]

I would agree with KraHen's opinion.

[CptSky]

KraHen is correct. Iterating through the broadcast set (screen) is enough. You will never have a lot of players on screen (without crashing the client), and iterating through hundreds of elements is really, but really fast.

The idea of the cell having the attribute is nice, but it's at least one byte per cell, for every map. At the end, you'll end with a lot of MB used only for that. (Could be merged with the altitude, and the access maybe.)

[Aceking]

What I did, was:

Every player tick (500ms), I would check to see if the player is casting LT.
If they are, iterate through their current screen and get every player within 3 tiles.
If they aren't second reborn, I would set their absorb timer to 3 seconds.
Then 3 seconds later, if the player is still there, start the luckabsorb.

Obviously a little more complicated than that, but you get the general idea.

[Spirited]

A better option might be to give observers in that smaller area lucky absorb until they move or teleport away, or until the caster cancels the spell (where it then checks the observers around the actor and rechecks for other casters).

[Y u k i]

We did a simple loop for the screenobjects. The loop runs once every second, our player tick is at 100ms.

If they are in range we set IsPraying to true, inside the location x,y,map accessor we have it set to false if the value changes. There are a few more places were we invoke the IsPraying but you get the idea. Tileflags sound nice too, however since there is always a player casting luckytime you simply do a rangecheck on that player and player "B". For traps, flags would be a great way to handle them.

[KraHen]

What you`re talking about (flagging tiles or areas) is a commonly used concept in 3D games, only not with tiles, but with specific areas given by a KD-Tree, for just one instance, or a quadtree for polygon based 2D games (for collision). But in this context, it`s just unnecessary.

[Korvacs]

Originally Posted by KraHen

What you`re talking about (flagging tiles or areas) is a commonly used concept in 3D games, only not with tiles, but with specific areas given by a KD-Tree, for just one instance, or a quadtree for polygon based 2D games (for collision). But in this context, it`s just unnecessary.

Tile flags are a required addition to a Conquer server, there's an entire system based around it.

[KraHen]

Originally Posted by Korvacs

Tile flags are a required addition to a Conquer server, there's an entire system based around it.

I guess you`re talking about the squamas/traps, yes, that could be expanded for this, but I still think it`s not worth it, if your screening system works as it should. Anyhow, performance wise there shouldn`t be any overhead doing one thing or the other (okay, maybe 1 microsecond - who cares, really), but I tend to follow that old agile rule - make it work asap (not talking about naive implementations of course).

[InsomniacPro]

What issues would one find with the system I initially thought of?

[Spirited]

I revoke my previous statement. I thought about other options you may have, and I came to the same conclusion as Jack did. Every source should have some sort of bit flag enumeration type implemented for tiles. I know it's costly in C#, but it is entirely necessary to efficiently manage the game environment. If such a system is going to exist in your source, you should definitely take advantage of it. Checking the character's tile is much more efficient than checking multiple / entities in the screen.

[InsomniacPro]

Originally Posted by Spirited

I revoke my previous statement. I thought about other options you may have, and I came to the same conclusion as Jack did. Every source should have some sort of bit flag enumeration type implemented for tiles. I know it's costly in C#, but it is entirely necessary to efficiently manage the game environment. If such a system is going to exist in your source, you should definitely take advantage of it. Checking the character's tile is much more efficient than checking multiple / entities in the screen.

Exactly, I would think it is less work just to check your single location, instead of enumerating through multiple objects within a screen. Working the same as checking for invalid locations when moving, just checking if the tile has a blessed flag.

Edit:
What I'm probably gonna end up doing is this, base_X and base_Y being the players coordinates
Whenever someone casts lucky time,

int base_X = 10, base_Y = 10;

int lowerX= base_X - 3, lowerY= base_Y - 3;// Lowest possible coordinate value.

for (int x = lowerX; i < lowerX + 6; x++)//Enumerate through all possible X values.
{
    for (int y = lowerY; j < lowerY + 6; y++)//Enumerating through all possible Y values.
    {
         map.SetBlessedTile(x, y);
    }
}

[KraHen]

Originally Posted by InsomniacPro

What issues would one find with the system I initially thought of?

Nothing at all. It was just my personal preference to go the other way around. Also bit operations aren`t costy at all, they`re probably the fastest operations you can do.

[Spirited]

Originally Posted by KraHen

Nothing at all. It was just my personal preference to go the other way around. Also bit operations aren`t costy at all, they`re probably the fastest operations you can do.

You're correct, but comparisons are still much more costly than single operations, which is why it's a good idea to avoid overusing them. Don't take my word for it though, look into it yourself.