Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

6) Is easy, just set the accuracy field to a really big number (all buff moves currently have 999 accuracy so they basically can't miss, though you might wanna go even further just to be sure).

1) There's no weather system currently. I'd probably implement this as a pair of global variables (weather type and remaining duration). At the end of every turn, count down the duration, and if it reaches zero, reset to "no weather" and display a message. Altering damage for certain types would be done in the script named compute_damage: simply check if e.g. it's raining and you use a water or electric move, and if so, change the multiplier variable accordingly. Effects like sandstorms/hailstorms dealing damage could be put in the same place ailment damage happens.

2) The easiest way to do this would be to implement a new Side Effect, I guess: the move itself does nothing, but has a 100% chance to add a "readied move" status which makes you skip the next turn's action assignment, and automatically enqueue the readied move (similar to how Sleep/Paralysis works), which would be special normally-unlearnable moves that unleashes the actual attack. These could be instance-variables in the battlemonster objects instead of something you store in the AMP data, similar to the buff array.

4) This is pretty straightforward, currently moves are added to a priority queue (with action_slate) using purely the monster's speed as the sorting factor. You'd add a new field to move data for "priority", which would be 0 for most moves but 1 for moves that strikes first; add a large number which will exceed the max possible monster speed stat (like 1000) times the selected move's priority value to the sorting factor when slating a move. (Also note you could give some moves negative priority to always happen last once this system is in place)

You'll probably need to increase BATTLEACTION_SPEEDBONUS_ITEM to 10,000 and BATTLEACTION_SPEEDBONUS_SWITCH to 100,000 while doing this, so high-priority moves can't happen before an item use or switch.

3) This would be a combination of the solutions to #2 and #4: give the protect move a high priority value (I think Pokémon gives protective moves 6 priority while Fake Out has 3, Extremespeed 2 and all other first-strike moves 1?) and make it apply a special 1-turn side effect (which is cleared when the turn ends) which just overrides the accuracy check ("if(random(100) <= acc-eva){" in obj_battlecontrol's Step event) - i.e., you check for the "protected" status (another instance variable for battlemonster objects) and if true, you enqueue a priority action that displays a message that the move failed due to protection rather than doing the regular hit chance check.

5) Currently there aren't even critical hits in the game, so I guess the easiest way to do this would be to add a "crit%" field to the move data and do a separate crit roll in compute_damage, returning an additional value, true/false depending on if it was a crit or not - this would affect the message and potentially sounds/visual effects... you'd also update the damage value accordingly, since crits could ignore defense... so you'd need to do this check early on. I think the easiest place to do this would be right before the "read level" segment: do a crit roll based on the new field (global.move_data[move,mvd_CRITCHANCE]) and if true, set def_buff to min(def_buff,1) and multiply atk_stat by 2. (And to make a crit guaranteed, set the crit chance to a number greater than 100)

Awesome, thanks for the in detail response there, the support you're giving is top notch. 

As an aside, do you have any plan to implement any new features to the framework at any point, or is what is offered now the final product from you? More curious than anything, what you've already provided is an amazing product for games like this to get off to a great start so I'm very happy with the purchase :)

I consider it done and final - the way Game Maker projects works, it would be really hard for people to just import the new features into their existing games, anyway, so I'd actively give people a problem if I messed around with it too much. If a new GM change completely breaks it, I'll release bugfixes, though. (array_length_1d is used all over the engine but has been deprecated, for instance, so that might become an issue at some point... easy to fix once you know about it, but I don't wanna force my paying customers to go through that just because I'm lazy!)

(+1)

Okay, I understand and it makes complete sense. Thanks.