How to structure your attack handler proper.

05/23/2011 12:21 BaussHacker#1
Note: There is no calculations or codes really, but more a good way to structure your attack handler, so it's easy to edit in the future or add new things.

Note 2: It's the way I would do it, maybe you like to it do it different.

Note 3: It's all pseudo.

Let's say you have your main attack handler.
Code:
public static void Attack(Client client)
{
}
Then I would do a main attack handling & split it up to the different attack types. Physical, Magic & Bow.

Code:
public static void Attack(Client client)
{

// Main attack handler here.
    switch (client.AttackType)
    {
        case Physical:
            PhysicalAttack.Process(client);
            break;

        case Magic:
            MagicAttack.Process(client);
            break;

        case Bow:
            BowAttack.Process(client);
            break;
    }

}
Then I would do a class for every attack type & it should contains a void called Process, which is handling the process for that type.

Example:
Code:
public class PhysicalAttack
{
    public static void Process(Client client)
    {
    }
}
Now you already have a good structure for your main attack handler, but how can this be useful?

Instead having a bunch of codes in your attackhandler, then you can easy edit current things or add new things.

Don't make it harder for yourself, that's important.
I would do an integer for every function that should be parsed before the actual attack handler. It could be arena, tournaments or something other.

Then if it returns 0, then it should continue to the main attackhandler. If it returns above 0, then it should not continue to the main attackhandler.

All the calculations etc. should be done before the attackhandler.

Example on how to add a function.
Let's use the current code we have.

Code:
public static int Safe(Client client)
{

    if (client.Map != client.Opponent.Map)
        return 1;//Instead returning true at the start, then do it after the handler.

    return 0;
}
public static void Attack(Client client)
{

if (Safe(client) > 0)
    return;

// Main attack handler here.
    switch (client.AttackType)
    {
        case Physical:
            PhysicalAttack.Process(client);
            break;

        case Magic:
            MagicAttack.Process(client);
            break;

        case Bow:
            BowlAttack.Process(client);
            break;
    }

}
I know there is not much info, but I hope you find it useful.
Remember I would have the functions in a seperate fil!
05/23/2011 17:26 |NeoX#2
I am also a friend of more small voids than one big one.
But seriously, everyone should do it as they like it, sure a company who hires someone will have their standards and your way is much more readable for sure, its up to them how they work.

I agree to your formatting.
Finally you move away from that eye-cancer causing coding style u had when you started :)
05/23/2011 17:32 InfamousNoone#3
[Only registered and activated users can see links. Click Here To Register...]
BOWLATTACK
/troll

Any how I fairly agree with the way it's being handled. It more or less coincides with my system scheme in ConquerServer_v2
05/23/2011 17:37 BaussHacker#4
Quote:
Originally Posted by InfamousNoone View Post
[Only registered and activated users can see links. Click Here To Register...]
BOWLATTACK
/troll

Any how I fairly agree with the way it's being handled. It more or less coincides with my system scheme in ConquerServer_v2
Oh wait a minute. I see my spelling mistake. :cool:
05/24/2011 00:37 pro4never#5
... Learn to use boolean return values....

But yes, most public sources already use this type of an idea. I know I personally do.
05/24/2011 08:20 BaussHacker#6
Quote:
Originally Posted by pro4never View Post
... Learn to use boolean return values....

But yes, most public sources already use this type of an idea. I know I personally do.
It doesn't matter. It's not operating faster.
05/24/2011 09:31 _Emme_#7
Quote:
Originally Posted by BaussHacker View Post
It doesn't matter. It's not operating faster.
It's not about operating speed here, but how easily read it is. For example, your "Safe" function, whereas Safe is a question that can be answered with yes/no, you should rather return a boolean than an integer.

Safe?
Do this
Not safe?
Do this instead
05/24/2011 09:41 BaussHacker#8
Quote:
Originally Posted by EmmeTheCoder View Post
It's not about operating speed here, but how easily read it is. For example, your "Safe" function, whereas Safe is a question that can be answered with yes/no, you should rather return a boolean than an integer.

Safe?
Do this
Not safe?
Do this instead
True that.
05/25/2011 14:03 KraHen#9
typedef int bool;
05/27/2011 14:29 ImmuneOne#10
Quote:
Originally Posted by KraHen View Post
typedef int bool;
..