Yal's Monster Collector Engine

global.monsters_caught and global.monsters_seen are arrays of booleans, which means each slot is true if you have caught/seen that monster and false otherwise. In this case you'd just want to carry over the counter itself, since it's the monster ID - so menuvalue_y for the currently hovered item (since it's a vertical menu).

Also, in the moncyclopedia when setting up the events (ggui_menu_region statement) you'll see we give every line a NONE event (which means nothing happens if you press the "accept" button with it highlighted), for your case you'd maybe want to make this conditional - if the monster is available for purchase (global.monsters_caught[d] is true) you'll set up a shop event (which e.g. checks if you can afford the monster and if so proceeds, carrying over the current menu's menuvalue_y as the monster ID the next-level menu refers to), if it's not available (e.g. you haven't caught it yet) you create a NONE event instead.

You'll need to change the mev_terminal_grab script a bit. This line

if(amp_read_var(AMP_FIRST_ACTIVE,amp_MONID) == NONE){

should be changed to

if(amp_read_var(AMP_FIRST_ACTIVE,amp_MONID) == NONE || amp_read_var(AMP_FIRST_ACTIVE + 1,amp_MONID) == NONE){

and now emptying either of the first two slots in the party (by going below 2 party members) should cancel the operation.

(Also, you probably want to update the message that is printed when this happens to read "2 monsters" instead of "1 monster", a little further down in the script)

gguielt_CURRSPRITE element type (added with ggui_element_sprite_current script) is the icon sprite of the currently hovered item in the menu, this is what you want to use here.

Since the data is filled into the menu using ggui_menu_add_option_text it fills the sprite data with NONE, but you could copy ggui_menu_add_option_text and create a new script ggui_menu_add_option_text_and_sprite that also fills the sprite/image data (the two arguments to ggui_fill_meta that are set to NONE within ggui_menu_add_option_text) using two new arguments at the end, and then use that instead in mev_battle_attack. (There's already the _icontext and _gridimage helper scripts that fills the sprite data, but they also set up the elements so that the image is used directly there in the body of the menu, which isn't what you want for this - we want this new script that fills the icon data but doesn't use it yet)

Interestingly, the problem does not occur if the battle is a hoard battle... Hmm.. There must be something I need to fix with 1 v 1 battles I think

Let's start with the easy bit, animated sprites. Just create a GGUI sprite element with the subimage set to -1, and it should work (draw_sprite uses the current animation subimage of the object if you draw a sprite with subimage -1, and sprite elements are drawn with draw_sprite passing through all parameters as-is). Potentially you might need to give the menu object an animated sprite as well (by assigning sprite_index) but I think it'll work even without it.

Now for "certain items with a different color": It's a bit unclear what you mean by "items" here? Items in the inventory or GGUI elements?

The idea with (Scrollable) Arbitrary Text elements is that you have a text field that reads data from the currently highlighted menu item rather than being a preset text (they're "arbitrary" as opposed to the Description field which originally was the only per-element-changeable text, and hardcoded text strings - I added the arbitrary text fields because I realized sometimes you need more than one per-element text field).

So basically, the element itself has no text, just a reference to the Arbitrary Text Array for that menu. But the Arbitrary Text Element owns the formatting (font, color, alignment) so by default, it can't change depending on what's highlighted - you'll need to make a new type of element which accesses an array of both text and formatting information (studying how gguielt_ARBTEXT works internally and copying the behavior for a new gguielt_ARBTEXTWITHFORMATTING might help here - you'd use an array similar to menu_arbtxt but rather than just storing text, you'd store a tuple [text, font, color, halign, valign]).

But if you just want different fields to be different colors (e.g. HP is red, money is yellow) it's very simple, use ggui_element_text_settings to change formatting parameters (all further text elements are created using these settings until you change them again).

Good job sticking with the project for 6 months! I'm used to people giving up much sooner but seems you're one of those rare determined people that actually finishes their games ^__^

Your analysis is pretty much correct!

Adding temporary mons would be pretty easy, as you can see in obj_battlecontrol's step event ctst_ACTIONSELECT block, it loops over all existing monster objects when building the list of who gets to act, so just creating instances should work. You should add a new "is_totem" variable to the battlemonster object so that totems are treated differently, though (it's always false, but when creating a new instance for a totem, you'll set it to true after creating it).

You might wanna do some changes in obj_battlemonster's bmonsterstate_DIE  to change the KO messages for totems (and delete the object if dead - an empty slot currently still is a monster object!) so they're not around when the ctst_REINFORCEMENTS step happens, or that team will be able to send in additional monsters to take the place of any destroyed totems, turning it into a permanent team size upgrade for that battle.

You will also need to change this block:

default:
    //Most ailments don't bypass action input, so let's go do that.
    if(next.side == side_PLAYER){
        substate = bcontrolstate_ACTIONSELECT_PLAYER
    }
    else{
        substate = bcontrolstate_ACTIONSELECT_ENEMY
    }
break

Totems should always go to bcontrolstate_ACTIONSELECT_ENEMY (automatically select), regardless of if they're player or enemy. (Unless you want players to be able to control what their totems do, of course - I'm just interpreting your description as totems being kinda passive/automatic)

Their buffs could be implemented as new moves with the appropriate target range set up (e.g. movetarg_ALLALLY to buff all allies), then you have the new totem species learn the buff-moves it should provide at level NONE (i.e., always knows them).

Since all monster stats are read from the AMP and the battlemonster objects just have a pointer to that (rather than having their own stat variables), I'd say you could put totem data in the "enemy" section of the AMP (since that's temporary data which gets cleared after a battle) - just run amp_get_new_enemy_id / amp_generate_monster using the totem species for this. You just need to manually free up slots again (with amp_clear_monster) when a totem is destroyed so you don't run out of slots entirely if a long battle has many totems created and destroyed.

Let's start with the easy part, how to enable the mouse cursor. Open the Game Options, then Windows, then the Graphics tab and check this box:

(if you want to draw your own cursor you could draw a sprite at the built-in variables mouse_x, mouse_y - each of the control objects could do this)

Having actual mouse control is considerably more complicated but I think something like this would be the easiest way:

• Edit ggui_menu_handle to comment out all the keyboard controls
• Add a new loop that goes through all frames and does something like this:

if(active){
for(c = 0; c < ggui_frames;c++){
  if(mouse_x > ggui_frame_l[c] && mouse_x < ggui_frame_l[c] + ggui_frame_w[ c]){
  if(mouse_y > ggui_frame_t[c] && mouse_x < ggui_frame_t[c] + ggui_frame_h[ c]){
     //We're in this frame, select it
     for(var d = 0; d < menu_w; d++){
     for(var e = 0; e < menu_h; e++){
         if(menu_frame[d,e] == c){
             menuvalue_x = d; menuvalue_y = e;
             if(mouse_check_button_pressed(mb_left)){
               //Clicked something! Run the regular "A button" code
               if(menu_event[menuvalue_x,menuvalue_y] != NONE){
                   sfx(snd_menu_ok)
                   script_execute(menu_event[menuvalue_x,menuvalue_y])
               }
               else{
                   sfx(snd_menu_buzzer)
               }
             }
             break; //End when we find the first frame that matches
         }
     }
     }
  }
  }
}
}

Now this will remove the "cancel button" option you had before but you could solve that by adding a "X" button in the top right corner. (You still need to preallocate enough menu options for all buttons but since the player needs to physically hover them you could put any "padding" buttons offscreen if you need to allocate more buttons than you'd physically use)

(actually maybe it would be easier to handle the X button out of GGUI entirely - just draw a "close" button at the top-right of every menu frame and check if you're in the top right 16x16 pixels of the menu in the Mouse Left Released event, if so destroy the instance and don't even check for frames)

There's more stuff you could do here, like playing the "menu move" sound when you detect that you changed either menuvalue_x or menuvalue_y, but this should be a good starting point.

I was wondering is there a PDF for it or just reference the features mentioned to edit it & thank you

Intriguing; I know GM is a bit weird with cross-compiling setups but I've never heard of anything like that. I guess some project paths won't get updated automatically unless you save on Windows and it was still using the ones from my computer...?

Anyway, onto your questions:

1) The attack is applied inside the loop in obj_battlecontrol's step event at line 672 (after the "//Apply to all target(s) individually" comment). The variable trg is set to each target individually; for your use-case I guess you would want to check whether that is a player or enemy character and do different things (it's the ID of a battlemonster object so just check its side variable) - for enemies you can keep the current system, but for players you'd branch out and create a minigame object instead, and it is responsible for applying damage, side effects etc depending on the minigame result. If it's a child of parent_battleturn the RPG turn flow should automatically wait until it destroys itself with no further action from your side.

(Basically add an if statement that checks if trg.side == side_PLAYER, if so create the minigame; then put the entire existing code into the else block)

If you want different minigames for different attacks, the easiest would probably be to extend the move data (see init_moves / init_move) and add a new field for "minigame spawn script" which is run when the move is performed, creating the appropriate minigame object(s) and setting parameters for damage etc.

2) I'm thinking the easiest way would be to give each enemy monster species an array of dialogue-options / script pairs, and then you start a cutscene where you immediately deploy a cc_question that uses it - basically what cis_shrine does, but you'd use a monster-species-specific variable for the menu alternatives rather than a hardcoded array; each of the scripts that are run when you pick an alternative would either display dialogue, enqueue extra attacks, or alter a "progress" variable in the affected enemy (or whatever else you want the dialogue system to be able to do)

For this system to work, there's a couple things you need to do:

• There's two places where obj_battlecontrol's step event checks that there are no parent_battleturn instances; those checks need to be extended to also check that there's no obj_cutscenecontrol.
• The monster data needs to be extended with a new field, the array of their dialogue options. You'd just store this as-is. (Game Maker didn't support arrays inside arrays when I made this engine so things like moves are broken up in the engine right now, but that's not a limitation anymore)
• You'd need to add the "talk" option to the turn menu, its setup code's currently located in obj_battlecontrol's step event on line 359.
• Figuring out who to talk to - so you can load their dialogue data into that dynamic cutscene - might require you to select a target, check out the code in mev_battle_attack_select for an example of how to do this.

It's gonna be a bit complicated but I think this should work:

1. in mev_pause_monsters_status, assign a new script to the script_step variable of the new menu that is created.
2. This new script should check for left/right presses and if so do some stuff; we'll get to that in a little bit. Note that the menu objects already get_keys() every step so you only need to check the input status variables - if(k_l && !p_l) to check for a left press, etc.
3. In mev_pause_monsters_status there's a giant block of code that creates the entire status menu. Break that out (everything inside the with loop) into a new script which takes two arguments monsamp and monid, these are the variables we use to read the selected monster's data - changing them to script arguments lets us reuse this blob of code without having to change it.
4. In the new script, additionally add a new line of code at the top (before the call to ggui_menu_preallocate) which should be ggui_frames = 0; (this lets us reset the menu completely - if you haven't noticed it already the frames are containers for all other GUI elements and resetting the frame counter like this will override the old data with new data without the system noticing)
5. In the now-empty with statement in mev_pause_monsters_status, add a call to that new script that just passes in monsamp and monid as the arguments, and additionally my_monster = other.my_monster so that we pass in the status menu's reference to the party.
6. Now we can fill in those left/right events: they should first update my_monster (add or subtract 1; if below AMP_FIRST_ACTIVE or above-or-equal to AMP_FIRST_ACTIVE+PARTYSIZE_ACTIVE, add/subtract PARTYSIZE_ACTIVE to loop back to the other end of this valid range; repeat the operation if the monster in that AMP slot is empty), then recompute monsamp/monid as currently done in mev_pause_monster_status, and then finally call the menu-setup script with those values.

You can of course extend this to terminals as well, though you'd need a modified version of the left/right check step script that also knows that box the monster is in, and loops the cursor around its range.

1) Stat total is the actual total stat distribution for the monster; the values inputted for the individual stats are scaled up so that their sum will equal this value. (This means you don't need to do the math to ensure all monsters of a particular tier are balanced, and the values for each stat only need to make sense relative to each other).

2) Not currently. There's a couple of ways to fix this, I think the easiest would be to rework how special effects work: currently, it's an array that must have 4 fields (or be empty) and they're unpacked into 4 separate scalar fields in the move data structure in init_move. (Chance, type, detail and severity). But you could just store the special effects array as-is when initializing the move; this lets you have as many fields in the array as you want. Specifically, you'd wanna have zero or more sub-arrays, each of which is a 4-element array with the same data special effects have now. When applying side effects (obj_battlecontrol's Step event, after the two comments "Side effects (target)" and "Side effects (user)", you'd loop over the outer of these nested arrays, and do the side-effect checks that currently exist for each element in that array (which would be a chance-type-detail-severity tuple). So for instance Dragon Dance would have the data

[
   [100,movespfx_BUFF,stat_ATK,1],
   [100,movespfx_BUFF,stat_SPD,1]
]

And to reiterate, this is an array with two elements; they just so happen to both be arrays with 4 elements.

3) Stats are always computed from the base stats, IVs, EVs and the monster's level. The final stats aren't stored anywhere, and stat points aren't added at any time. Check out monster_get_stat and the scripts it calls for the details.

The script mev_battle_attack_select will build this menu (listing only the targets that are valid depending on the move), and it creates an array "my_target" in the menu instance, which the menu later uses to slate the action when you confirm. Each entry in this array is the instance ID of a battle monster object, so you could just copy it (after it's been completely built) to your cursor object and then get positions etc by going through the instance IDs.

Now, your main question is how to keep this in sync with what you're selecting in the menu. It's pretty simple: script_step. Menu objects will execute this script after their regular menu-handing behavior if it's not NONE. (There's a whole bunch of these customizable behavior scripts for more complicated menus - check parent_menu's create event - but most of the time we only change script_draw)

Make a script that tells the battle cursor what the currently highlighted item in the menu is, and in mev_battle_attack_select, set the script_step variable in the menu to this script. (Heck, you could forgo the array-in-cursor entirely and just tell it to focus on an instance ID by having the menu check the array... that's probably easier?)

Also, you could use this to make the cursor automatically get destroyed when the menu is closed: in its create event and in this script, set an alarm to 2 steps. When the alarm happens, instance_destroy(). As long as the target menu exists, it will keep resetting the alarm before it can trigger, but when it's destroyed (after you confirm the target or cancel out), the alarm will run out and also destroy the target cursor.

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)

Not 100% sure what you mean with "add a mon to the party", is it a new mon or one from a box?

If the former, check out how mev_intro_starterselect_confirm does it: first get the first free AMP (=Active Monster Party) slot in the player party region, then generate a new monster there. The latter (swap out a pre-existing monster) is a bit trickier but there's code for this in mev_terminal_interact.

For multi battles, the important thing is setting the two variables global.player_side_monsters and global.enemy_side_monsters to the amount you want on each side (in your case both would be 2). Check out the scripts cc_battlestart_trainer and player_step_fill for trainer and random encounters respectively.

None of those are included by default, but since this is just a Game Maker project it wouldn't be impossible to include them.

• More than 4 moves per monster would be relatively easy, just add a few more fields in the monster data structure and increase MONSTER_MAX_NUMBER_OF_MOVES accordingly. The biggest effort here would be to resize menus so more moves will fit visually.
• Item to teach a monster a new move would be a bit more work (needing some custom menus) but ultimately you should be able to leverage the existing code for learning a move by levelling up here. You probably want some data structure for which monster can learn which moves, too (a big reason I didn't include this was because I figured it was too much work setting up a system like that which would still work for every user's use-cases).
• Passive skills would need to be added to the monster species data, but ultimately would be similar to held items (check obj_battlecontrol's step event and look for all calls to the function "battle_item_might_affect_this" - you'd basically do the same type of checks, but for passive abilities). I.e., the skill has a trigger condition like "on damage" or "after your turn", and you check if the affect monster's passive skill has that trigger; if so, you invoke its effect script. (And then the script decides if anything happens - an ability like Flash Fire or Spiky Body only triggers its effect on certain types of moves but you would run the script every time the monster takes damage anyway and let it decide based on current attack data and such)

Strain = lose extra MP when doing a move. (I got the idea from Shin Megami Tensei). It's basically the "Spite" move from Pokémon, but as an ailment.

No plans, sorry. (The hardest part with making a collectible card game is making all the rules, and that's a very per-game-specific thing that's hard to make a general system for)

Move IDs are stored in global.active_monster_party[amp_id,amp_MOVE1] through global.active_monster_party[amp_id,amp_MOVE4] and then move data is stored in the global.move_data array.  So after you get a move ID from amp_MOVE1...amp_MOVE4 you can look up global.move_data using the ID you looked up and the move data constants (they begin with the prefix "mvd_")

There's no built-in system, but it should be easy enough to set up.

In obj_player's collision event with obj_encounterzoneselector, after line 8 insert some new code:

for(var b = 0; b < array_length(global.encounter_valid_monsters); b++){
  for(var c = AMP_FIRST_ACTIVE; c < AMP_FIRST_ACTIVE + PARTYSIZE_ACTIVE; c++){
    if(global.active_monster_party[c,amp_MONID] == global.encounter_valid_monsters[b]){
      array_delete(global.encounter_valid_monsters,b,1)
      b-- //Deleting shifted everything back one step so re-check
      break;
    }
  }
}

(this is completely untested so use with care)

the encounter_valid_monsters array is common to all ects_* (EnCounter Table Setup) scripts so modifying it directly like this means it should work everywhere in the game.

I think the easiest way to do things like this would be to expand global.monster_data and add a "draw script" field. Whenever the monster is drawn, invoke this script instead of just draw_sprite/draw_sprite_ext (you can find all cases where a monster is drawn by doing a project-wide search for the "mond_SPRITE_BATTLE" constant). For monsters that don't need any special drawing, you'd add a default script that just draws the sprite like normal.

This is gonna be a bit tricky since a lot of the drawing is in menus (shrine terminals, status screen etc) so you'd probably need to add a new type of GGUI element that contains both a sprite and a script to draw it with (right now monsters are drawn in menus by creating a sprite element containing their sprite).

For the random markings themselves, the easiest way would be to use random_set_seed() and construct the seed from something that's unique to the monster and won't change - e.g. some sort of hash of their IVs (or you could give them a new "ID number" field set to like, irandom(9999999) when generated with amp_generate_monster() if you think that's easier), then generate the random coordinates to draw with, and finally randomize() to reset the RNG again. This way, the random numbers will always be the same for the monster, but you don't need to store them in any way.

Yeah, just include the value of global.player_name in the message.

Easiest way would probably be to make a new type of signpost (a child of the obj_signpost so it "just works" with the existing interaction code) whose interact_script is cis_npc_polyliner and then give it a new expression-typed variable "my_messages". For each sign you place you'd then give it a messages value like:

[tsprintf("This is %'s house!",global.player_name)]

(So it contains an array of strings, with only 1 value - this is different from just a regular string, since cis_npc_polyliner loops over the array of messages, so don't forget the []'s around it)

(The reason the default signpost doesn't work is that it has a string-type variable, so it'll just include the variable / tsprintf call as text instead of running the code. You could of course change it to expression-type in the base sign instead, but that breaks all existing signposts unless you manually add quotation marks around their text...)