Yal's Monster Collector Engine

Here's the official GameMaker tutorial series on the code editor. (I recommend using GML Code since Visual doesn't really make things easier, just prettier to look at.)

The part which applies the move is the part (starting at line 671) which begins:

//Apply to all target(s) individually
for(var c = 0; c < array_length(a_targ); c++){

Currently it doesn't do anything special to detect targets not existing, it checks if the number of hits is 0 and the number of misses is also 0 to conclude that there was no target after the fact. (Done immediately after this loop)

So what I'd do is insert a check before this loop, which checks if the original target remains, otherwise gets a random one based on the move (using the function enemies use to pick random targets):

found_targets = 0;
for(var c = 0; c < array_length(a_targ); c++){
     var trg = a_targ[c];
     if(battle_is_alive(trg)){
         found_targets++
     } 
}
if(found_targets == 0){
     a_targ = battle_get_random_targets(a_user, a_comm); 
}

I tried it out and also can see it, so something has changed with GM's processing order that causes this (it was always a bug but it just didn't happen before for some reason, lol - presumably the player was always handled before the dialogue boxes but now it's handled after and thus retriggers the interaction immediately after it closes)

It's easy to fix at least, just update the "Interacting" block of obj_player's step event like so:

//Interacting
if(interaction_cooldown){
     interaction_cooldown--
}
else{
     if(k_a && !p_a){
         var o = collision_circle(
             x + lengthdir_x(TILESIZE,drawdir) - TILESIZE*0.5,
             y + lengthdir_y(TILESIZE,drawdir),
             12,
             parent_interactible,false,true
         )
         if(o > 0 && instance_exists(o)){
             interaction_cooldown = 5
             with(o){
                 if(object_index == obj_npc || object_is_ancestor(object_index,obj_npc)){
                     drawdir = (other.drawdir + 180) mod 360
                 }
                 if(interact_script != NONE){
                     script_execute(interact_script)
                 }
             }
         }
     }
}

Then just initialize interaction_cooldown to 0 in the Create event and everything should work as expected.

Yeah, all of the grid stuff will need to be custom-made, because there's no concept of positioning and ranges in the engine currently.

What I'm thinking will need to change:

• obj_battlemonster currently just has its position as a visual thing, it will need to be able to move around... but more importantly they need to keep track of their current grid cell (because that's ultimately what matters, their x/y position is just a representation of that)
  • obj_battlemonstercircle is just a visual object representing the ground currently, but could probably be repurposed into grid squares; you'd give them variables for which grid cell x/y they represent and then be able to use them for reference for where to place monsters + maybe let them keep track of which cells are occupied or not. And then rather than always creating two, you'd create enough for the entire grid.
• battle_get_valid_targets needs to take positioning and range into account, and in turn move data needs some new stats to store those (which would be added to init_moves/init_move).
  • Additionally, mev_battle_attack and bcontrolstate_ACTIONSELECT_ENEMY should be updated to do nothing if there's no valid moves to use instead of enqueueing the desperation attack (unless there's a target in range)
    • bcontrolstate_ACTIONSELECT_ENEMY additionally will need to select a new "move" action sometimes, e.g. when there's no targets in range. (And presumably you'll need to add a new action to the player action selection menu as well for moving, see bcontrolstate_ACTIONSELECT_PLAYER)
  • mev_battle_attack_select currently creates a menu to select targets when there's multiple targets and a move targets a single target; you could keep this menu but have it also discriminate by range and positioning. If you're OK with it just listing targets that should essentially be the only thing you need to do, but if you want it to highlight the grid cell you're targetting it gets a bit more involved - creating a GGUI region with no background sprite which covers the entire grid, then placing highlight regions so that they line up with individual grid cells. (Check out msh_terminal_load_page's section "Middle main: Box contents" for an example of how to make a grid menu, but the TLDR is that you want one "ggui_menu_region" for each cell, after ggui_menu_preallocate'ing a grid with as many cells as your battle grid). These cells's menu event field would be filled in with NONE if there's no valid target there, mev_battle_attack_select_target if there is.
  • Likewise, you'd do basically the same thing for selecting a cell to move to, except you have NONE if a cell is occupied and a new mev_battle_move_confirm_destination event if it's not + within your move range. (You'd probably want to add sprite elements to each cell which are just a red/green rectangle which represents if it's valid or not)
• Currently obj_battlemonster remains even if the monster is KO'd and just is invisible, you'd probably want some extra logic to move them out of the grid when they're not replaced with backup so that a dead monster can't impede pathfinding and be selected as a valid target. Just setting their grid cells to a big negative number (like NONE) might be enough, as long as you don't try actually accessing the grid data if the position is NONE.

The change was to not modify argument0 directly, but to use a helper variable to hold it (I don't remember what the compilation error was but presumably argument is read-only after 2.3)

The current version looks like this:

///tsprintf(format,...)
function tsprintf() {
     //Trivial String Print Format
     //Replaces each % percent sign with an argument, then returns the string.
     //Inteded to make writing debug printouts less painful.
     var c, s = argument[0];
     for(c = 1;c < argument_count;c++){
         s = string_replace(s,"%",string(argument[c]));
     }
     return s;
}

Both of these will need you to track some additional data, I think two global arrays with AMP_PARTYSIZE_ACTIVE slots will be enough: global.party_was_in_battle and global.party_last_move_selected.

• In obj_battlecontrol's create event, fill these both with 0's in all slots.
• For only earning EXP in battle:
  • In obj_battlecontrol's step event bcontrolstate_WIN_STEP section, change "if(amp_has_monster(exp_monster)){" to "if(amp_has_monster(exp_monster) && global.party_was_in_battle[exp_monster]){"
  • In obj_battlemonster's step event after the "//Monster's been seen in battle! Add to list." comment, add "if(amp_id < AMP_PARTYSIZE_ACTIVE){global.party_was_in_battle[amp_id] = true;}"

• For remembering the last move selected:
  • In mev_battle_attack_select, right at the top add "global.party_last_move_selected[obj_battlecontrol.action_monster.amp_id] = menuvalue_x + 2*menuvalue_y"
  • In mev_battle_attack, at the end of the "if(validmoves > 0)" block somewhere, append a switch state like

if(obj_battlecontrol.action_monster.amp_id < AMP_PARTYSIZE_ACTIVE){
switch(global.party_last_move_selected[obj_battlecontrol.action_monster.amp_id]){
  case 0:
    menuvalue_x = 0
    menuvalue_y = 0
  break;
  case 1:
    menuvalue_x = 1
    menuvalue_y = 0
  break
  case 2:
    menuvalue_x = 0
    menuvalue_y = 1
  break
  case 3:
    menuvalue_x = 1
    menuvalue_y = 1
  break
}
}

Easiest way would probably be to edit cis_intro_part2 and swap out the cc_intro_startermonsterselect / nickname logic; rather than making a monster choice menu and wait for your input, the startermonsterselect script would instead fill your party with the monsters you want:

var amp = amp_get_new_party_id();
amp_generate_monster(amp,monster_id,level)

First get the ID of the first empty slot in the party, then generate a monster there using its species and level, repeat as many times as you want. There's matching get-first-free-slot functions for the boxes and the temporary enemy slots, too.

To go through every monster like this, rather than hardcoding the monster_id you could loop from 0 to MONSTER_MAX.

Also note that if you really want the player to have every monster in the party, you probably want to increase PARTYSIZE_ACTIVE from 6.

Hi Yal! me again.. I've gotten things going and I'm almost there where this works but now I can't seem to figure out how to add a room in the indoors room.  There is no code in the door object and i can't find the script that gives x and y coordinates for the indoors room.  The purely script based engine is very hard to get used to. I'm used to engines with more object based code than scripting.    I also added another tile set for the indoors and the engine crushed it.  Is the room getting resized upon output?

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.