Competitor Diary

[Surgo]

I don't want to keep clogging chaos's discussion thread so I'm going to post these in a separate thread.

6/12/07 so far:
I finished implementing the first Hook_Object and its corresponding Hooks. The Hook_Object class is entitled Common_Hooks::has_run_reset and a global object has been defined for it that all Hooks should reference, entitled Common_Hooks::has_run_reset_hook. The Common_Hooks namespace, as its name sounds like, is a collection of "example" Hook_Objects that are also used in various places by the engine.

This Hook_Object iterates through every hook in the list that contains the referring Hook that called it, and sets the has_run variable of every Hook in said list to false. It's the first Hook of many that has been created so far. At the very beginning of a battle, the engine calls BattleState->setup_hooks, which creates a Hook in every Hook list that references this Hook_Object. Said Hook_Object has priority 999, ensuring it is always the last hook that is run when the list is iterated through.

In other news I pushed the hook priority variable back to the Hook_Object class where it really belongs, instead of the Hook class.

The difference between Hook and Hook_Object can be a little confusing. A Hook is what attacks and the engine places in various lists. It's something of a shell, not much more than a reference. It gets assigned a Hook_Object when it is created, and keeps track of a few things like which list it belongs to, which battle it belongs to, the internal state of the Hook, and whether or not it has been run yet. The Hook_Object is where the meat of what the Hook does is coded -- it takes various arguments and acts on them. The move Reflect, for example, extends the Hook_Object class. When someone uses the move Reflect in GSC onward, the code for the move creates two hooks, both referring to the Reflect Hook_Object. One of these goes in the damage-dealt hook list and gets called whenever damage is dealt -- it checks whether the damage was physical or special, takes the damage as an argument, and halves it. The second goes in the end-of-turn hook list and, when called, checks an internal state that starts at 5 and decrements it each time it's called. When it reaches 0, it removes itself and the other Hook from the hook lists. (It keeps track of what its "family" hooks are by a unique identifier.)

I probably won't do any more tonight because I have to finish some math stuff for work tomorrow and it's really hard.

TODO #1: Make the BattleState::add_hook function take a variable-length argument list, turn it into an argument map, and pass it to the Hook constructor, which should then pass it to a new function in Hook_Object to generate an internal state from that list. This is much, much better than making a state before making a Hook and then assigning the state to the Hook.

TODO #2: Make a function to give per-battle unique identifiers. Not difficult.

TODO #3: Something I thought of while I was typing this up. Instead of having the BattleState::add_hook() function create new Hooks, this functionality should be moved to the Hook_Object class, turning each Hook_Object into a "Hook factory". That way the Hook_Object can create all the necessary Hooks that the object needs for an instance, synchronize their unique identifiers, their states, etc., and add them to the necessary lists.

TODO #4: Implement a BattleState::desetup_hooks function, which deletes any remaining hooks at the end of the battle so we don't have a memory leak.

edit: Anyone can feel free to post here. I like keeping this updated with my progress because it forces me to work.

 

[Surgo]

Competitor log of 6/13/07:

I've finished TODO #2 and #4 of my last post. I've also just about finished the TODO #3 from my last post, but I need to change the function that adds hooks to the hook list a bit so it takes priority into account -- namely, a hook of priority b, where b > a, should be put after a in the list.

So, new TODO:

TODO #1: Make the Hook_Object::generate_hooks() function take priority into account when it adds its generated hooks to the various lists.
POSSIBLE SNAG: Could different lists need different priorities? I can't think of a situation where this is the case, but if it comes up I can make hook_priority an array of length LARGEST_HOOK_LIST_NUMBER + 1, instead of a single number. That way each list can have its own priority.

TODO #2: Make the BattleState::add_hook function take a variable-length argument list, turn it into an argument map, and pass it to the Hook constructor, which should then pass it to a new function in Hook_Object to generate an internal state from that list. This is much, much better than making a state before making a Hook and then assigning the state to the Hook.


Also thanks chaos for answering my really stupid question.

 

[Surgo]

6/14/07:

I did nothing today. My dad showed up with my car, which has been fixed from someone backing into it. That and the creation of my new team took up most of the day.

 

[Surgo]

6/15/07:

Completed TODO #2. I took Brain's suggestion of making a "struct Hook_Arguments" structure instead of variable-length arguments or a map<int, void*>, where the caller of add_hook() or run_hooks(list) creates such a structure fills out all the arguments available to it and passes it in. This is much cleaner than variable arguments.

I didn't have much time to work today because I have to wake up at 6 AM tomorrow to go to a mathematics conference (ugh).

TODO #1: Make the Hook_Object::generate_hooks() function take priority into account when it adds its generated hooks to the various lists.
POSSIBLE SNAG: Could different lists need different priorities? I can't think of a situation where this is the case, but if it comes up I can make hook_priority an array of length LARGEST_HOOK_LIST_NUMBER + 1, instead of a single number. That way each list can have its own priority.

 

[Surgo]

6/16/07

Thirteen...hours...of...math conference....send help...dying...

 

[chaos]

6/18/surgosgay:

looking at libevent. I need a framework that is crossplatform and this one seems to use the best possible polling method regarding the platform in question. While I could probably write a faster one for Windows using a bunch of crazy shit, that would be a waste of time.

 

[Surgo]

I said I was going to update this today, but it has been about 100 degrees outside with extreme humidity so every time I sit down in my room and look at my computer screen I just go "guuuuuuhhhhhhhh" in an imitation of how Pookar must feel every day of his life. Getting any sort of work done in my room is fucking impossible until this weather clears up.

 

[Surgo]

7/8/07:

Finished TODO #1. That's actually it for my last TODO list, I think hooks are mostly complete. Compiling a new TODO list right now...

 

[Surgo]

Things to do:

* BattleState::run_hooks() is the last piece of Hook code that needs to be implemented. It is theoretically simple.
* Very abstract classes need to be made for moves (fat Misty, are you there? fat Misty, I think this is your job!). If I wanted to implement Pound, I should just be able to write something like this:

class Pound: public Damage_Dealing_Move {
    Pound():
        Damage_Dealing_Move(power, accuracy, 0 (chance out of 255 for secondary effect), whatever parameters)
    { }
};

Or a move with a secondary effect like thunderpunch:

class Thunderpunch: public Damage_Dealing_Move {
    Thunderpunch():
        Damage_Dealing_Move(power, accuracy, 25, whatever parameters)
    { }

    void effect() { paralysis(target or whatever the parameters need to be); }
};

As you can see, we should probably have a bunch of functions in some namespace implementing some common effects like burn and paralysis!

 

[Surgo]

lol triple post, I like Brain's idea for moves better.

<Brain> I don't think there should be such a thing as Pound() and Thunderpunch()
<Brain> classes are cool but you're pushing it
<Surgo> here was my idea:
<Surgo> each Pokemon has Move[4] moves
<Surgo> when the user calls the move
<Surgo> turn handler goes:
<Surgo> user->team[current]->moves[movenum]->act()
<Surgo> after checking for things like PP and disable of course
<Brain> that doesn't mean you need to have a Thunderpunch class
<Brain> you can just do movedb["thunderpunch"] = DamageDealingMove(...)
<Surgo> I suppose that works too
<Brain> and for the paralysis effect, you would pass an Effect subclass to DamageDealingMove
<Surgo> with custom classes for more complex things like Perish Song

 

[Surgo]

Hook code is just about done. The only thing that's not completely done is BattleState->run_hooks(), and that is partially done.

What needs to be done to complete this is stuff like the Action class, and really finishing up and documenting how and why input to the engine is entered, checked, and accepted. There's a good section in the README.txt that I wrote about this, and I need to re-familiarize myself with it. It's a good thing I documented this stuff as I wrote it!

A good, long section of the README about hooks is also in order, I think.

 

[Surgo]

Just implemented the very last of the hook functions (BattleState::remove_hooks()), and made a huge wall of text in the README file detailing how to use the hook subsystem. I think I want to get started on the moves now.

 

[Misty]

Okay, so, I'm almost done with all GSC moves except 3... one is the infamous Baton Pass, the others depend on some things that remain to be coded.

Here are the major things that remain imo, not including implementations:

1) KO code. This is still going to be the most difficult aspect of the engine, and I hope you have this all planned out, because I'm pretty much leaving it up to you.

2) Still need ways to prevent certain actions. Taunt, Torment, forcing certain actions... I'd say it needs a hooklist, but maybe there's a better way.

3) Abilities and items... not really a big deal, though. I can do these.

4) A proper turn handler. Actually, this isn't a big deal either, just putting things together and issuing the proper hook calls.

 

[Surgo]

1) Yeah I'll get to it lol.

2) Ugh I'll think about this one...this basically involves action validation code which I gotta get to.

3) This is just like moves really.

4) Yeah this is no big deal.