September 1st, 2013 6:33 AMMaruno
It's a basic feature of Ruby. It occurred to me when thinking about online battles that the only information you really need to send across are the initial conditions (i.e. the party Pokémon at the start, not the battlers), the chosen commands and any outcomes of randomness - everything else is calculated. Knowing how an RNG works, I then figured you don't even need to send the outcomes of randomness; just sync the seed at the start and it becomes just more calculations. In theory.
An example of setting the RNG seed is in the Lottery mini-game. Here the seed is set depending on the day, which ensures the winning number is the same on any given day. You'll probably want to randomise it again afterwards to prevent any possible abuse (not that I think anyone will care enough to try it for a fangame).
September 1st, 2013 2:22 AMAlexandre
I must have missed the random number seed section while analysing the battle system, cheers for that!
August 31st, 2013 4:47 PMMaruno
That sounds like a very unnecessary way of getting online battles to work. If you synchronise the random number seed at the beginning of the battle for all participants, then all random events in the battle will be the same for both players (assuming identical code). This way you only need to send the information about which command is chosen, and play each round locally for each player, knowing that the RNG is playing out the exact same moves for each participant so there'll be no desynching.
I'm not sure how to answer your question. pbAttackPhase starts the activity and handles retreating and priority calculations. Then for each battler, in order of priority, that battler's pbProcessTurn is run. pbProcessTurn makes that battler use a move. The process of using a move is definitely a jumble of code.
August 31st, 2013 3:21 PMAlexandre
Not for debugging, for sending over a socket connection. (working on plug and play pvp battling). I figured out that problem anyway. PokeBattle_Battler has an instance variable @battle which refers back to PokeBattle_Battle. When attempting to dump the battler, the battle variable also gets dumped. PokeBattle_Battle contains the scene variable which refers to PokeBattle_ActualScene so in actual fact I ended up dumping the entirety of the scene and logic of the battle. Creating custom marshal dump and load methods for PokeBattle_Battler which excludes @battle (and @moves since PokeBattle_Moves also has a @battle instance variable) solved the problem.
Also, you wouldn't happen to have a layout of the battle logic and how, in specific, pbAttackPhase maps out the attack logic. I think I have the basics mapped out in my head but its difficult to keep track of, if not, cheers anyway!
August 30th, 2013 4:43 PMMaruno
What would you possibly want to do that for? Debugging purposes? Surely there are better ways...
You'll have put the dump code in the wrong place. Marshal.dump(@battlers) will work somewhere in PokeBattle_Battle and that's about it. Also, you can't really use that line all by itself - you'll need to open a file to dump it into - check other dumping for examples.
August 30th, 2013 10:09 AMAlexandre
Hey Maruno, trying to dump the @battlers variable in PokeBattle_Battle with Marshal.dump (in specific @battlers) however I'm getting "marshal_dump not defined for class viewport". I'm aware that Marshal can't dump certain classes however I can't find where viewport is called in PokeBattle_Battler, would you have any idea?