Yal's Monster Collector Engine

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...)

It's named "init_constants", should be right at the top of the Scripts folder.

• Keybinds are defined in Scripts-->UI-->init_input
• Local input variables are set up in Scripts-->UI-->init_keys
• Local input variables are updated in Scripts-->UI-->get_keys

So to change the default keys, you'd update init_input. To add alternate input like a controller, update get_keys.

E.g. instead of:

k_u = keyboard_check(global.input_key[input_U])

you might want something like:

k_u = keyboard_check(global.input_key[input_U]) || gamepad_button_check(global.active_gamepad,global.input_pad[input_U])

(and so on for all other inputs)

Player movement is handled in Objects-->obj_player-->Step event. I think it's easiest if you add 4 new cases for up+left, up+right, down+left, down+right (which moves diagonally instead of just along x or y) and then use "else if" between all cases instead of just "if" so only one case can happen at once. (If you want to add diagonal sprites this approach will help too)

It seems like "argument" is read-only now, you can fix it by updating the script like this:

Thanks, glad you like the engine! Looking forward to see what you'll make with it! ^__^

One of my first (failed) GM projects back in the early 2000s was making a game in this style, but it just failed miserably... it felt great to finally be good enough at coding to tackle it :P

Did you press Enter? The game uses Z / X for the accept/cancel buttons.

To evolve monsters, you need to take the following steps:

1) Store the player's current position (not necessary, but if you want them to be exactly where they were when you come back after the evolution, you should do this)

with(obj_player){
        global.load_x            = x
        global.load_y            = y
        global.load_room        = room
        global.load_direction    = drawdir
}

2) Put the monster in the evolution queue:

ds_queue_enqueue(global.pending_evolutions_queue,[monamp,species]);

monamp = AMP index of monster to evolve - when you do a batch operation, you should loop over the AMP indexes you want to affect (e.g. entire player's party is from 0 to PARTYSIZE_ACTIVE; party + boxes is from 0 to PARTYSIZE_ACTIVE + PARTYSIZE_BOXED)

species = monster species to evolve into (the global array global.monster_evolution_mon has all the defined evolutions, but you can force a monster to evolve into any other species if you want)

3) Finally, go to the evolution room:

room_goto_fade_dontdestroy(rm_evolution,60);

Nope, you can go as high as you want. The menus resize the sprites so they'll fit in the allotted space, but it doesn't happen in battle.

I'm not really interested. My day job keeps me in need of time more than money, and I'm already fully busy with my next new and exciting project. But if you have any questions about how to implement a new mechanic, feel free to ask it right here - I check my itchio notifications daily and try to answer every question!

It should be relatively easy to add in... there's a question from a few weeks ago about having separate sprites for the front and back that goes more in-depth, but here's the cliff notes version:

• monster_get_battlesprite is used to get the monster sprites, this uses the AMP ID of the monster to read sprites from so you could read its gender and then return different results if the species has separate male and female sprites.
• These sprites would need to be added in init_monster (instead of just a map and battle sprite, you could have map + battle male + battle female, or even separate male and female map sprites), and of course this also means you need to modify init_monsters so that it gives the correct number of sprite arguments in each init_monster call.

To avoid having separate handling for monsters with and without gender differences (which makes things complicated...), I'd just have them always have separate male and female sprites in the code, but add the same sprite twice if there's no gender differences.