Yal's Monster Collector Engine

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.

I haven't tried (I don't own any of the GMS2 mobile export targets) but as far as I'm aware the engine doesn't use any Windows-specific functions.

I think the biggest stumbling block would be lack of touchscreen support... if you go with the "virtual gameboy buttons" approach a lot of the mobile emulators used to play Pokémon games seems to have picked (where there's a D-pad and A / B / Start / Select buttons on the screen and the rest doesn't respond to touching) this is probably not a huge issue, but if you want full touch support for menus, you're going to need to add that yourself.

On the plus side, all GUI elements are defined with basically the same logic and are put in a single array, so on a touch event (i.e., Global Mouse Pressed) you can basically loop through all elements in the currently active menu and see if any of them are in the target zone:

For swapping two items, it's a bit complicated. I'm thinking it'd be easiest to duplicate inventory_lose_item into a new script called inventory_swap_item(itemID1, itemID2) and modify it so that it loops through the inventory twice, once for each item; once you have the two inventory slots, you just swap the ID/QTY data of those two slots using a temp variable.

Easy so far, but the tricky bit is GETTING the two item IDs you want to swap. If you want the Pokémon-style "press select" approach, I'm thinking you'd have some code in the script_step of the inventory menu (spawned by mev_pause_items / mev_battle_item) which checks for the 'select' button, and if so, memorizes the currently selected item (see mev_pause_items_select for an idea how to do that) spawns a new identical inventory menu (i.e. like in mev_pause_items / mev_battle_item) but uses NONE for its menu event script (the argument to msh_spawn_inventory) and another step script, which, if Select is pressed, memorizes the newly selected item, and if it's different from the first selected item, swaps the two items. In either case, it destroys itself, leaving you with the original inventory menu - but it should be updated to match the new sorting order, so you need to rebuild it. mev_pause_items_use_actually_use has a code snippet that rebuilds the item menu after the inventory potentially has changed, so apply that to the original inventory menu (easiest if you set the "daddy" variable of the "find the second item" inventory copy to the original inventory menu's id - just remember you'd loop over daddy instead of daddy's daddy when copying the code)

And of course, you might want a custom draw script for the "find the second item" menu that draws the inventory AND an extra marker for the first item, to notify the player that they're in a "rearrange the menu" state.

Side note: for multiple sorting options (e.g. A-Z, latest, etc) I'm thinking the easiest way would be modifying the msh_spawn_inventory_fill_list_category script, which builds a ds_list of all items of that "page" (items are actually stored in one big list internally instead of being divided into separate pages) - you could change that to a priority queue instead and have priorities based on the currently active sort mode.

mev_pause_items_use_actually_use has a code snippet that rebuilds the item menu after the inventory potentially has changed; copy that and use it to rebuild the menu whenever the player presses the "change sort mode" button. You could put this button check in the script_step of the affected menus, and note that you would apply the changes to the menu itself, not it's daddy's daddy, so remove the outer with loop.

The types, monster IDs and so on are colored red because they're constants. You can add them in the init_constants script. This is where the type constants are defined, for instance:

(You can define constants anywhere in GMS2 but it felt easier to have them all in one place for easy access)

Keep two things in mind: each constant of each enumeration needs to have an unique value (e.g. type_DRAGON should have value 8), and you should update the MAX constant to be one higher than the highest constant (e.g. after adding the dragon type, TYPE_MAX should now be 9) so the loops that goes through some things won't skip the newly added data. 

The easiest way would be to modify monster_get_battlesprite to return different sprites depending on whether the AMP ID is an enemy monster or not (right now it always returns the monster data mond_SPRITE_BATTLE column), player monsters would use a new mond_SPRITE_BATTLE_BACK sprite instead.

You can tell if an AMP ID is an enemy by checking if it's >= AMP_FIRST_ENEMY. If it's not, it's a player AMP ID. (If you're curious, AMP = Active Monster Party, the database of currently loaded monsters - player party, player boxes, and enemy party)

To add this new sprite data, you'd need to modify init_monster so that it takes three sprite arguments instead of two (currently it takes battle and map sprites, you'd want battle, battle_back and map), then update init_monsters (with an "s" at the end) so that it initializes the monsters with those three sprites instead of the current two.

Thanks for the kind words! ^__^

obj_battlecontrol is the heart of the engine, I think its state machine contains almost half the code in the entire engine... but it's not quite enough to import it alone since it also communicates with the menus, the monster/move/party databases, and battle monsters and effects are their own objects.

There's a lot of dependencies between the different things in the engine, but I think something like this would be a good starting point if you want the entire battle system:

• Everything in the "Battle" and "Menu" objects folders
• The "Menu" objects have dependencies to the Menu Events, UI, and Drawing script folders
• The "Battle" objects have dependencies to the Battle, Data Mangling and Effects script folders
• There's a lot of misc dependencies to the "Maths n String Handling" scripts (in particular tsprintf is used everywhere)

Importing all of these would be a good starting point, and then test-playing to see if you get any "unknown function was called" errors - then you can make a judgment call if you'd want to import that script or replace the call with one of your existing ones (like the sound effect / music scripts - you probably have your own setup for that if you're partway through a large project).

Good luck! Feel free to ask any questions you're stuck on here, I try to check my Itchio notifications at least once per day.

The ID of the move the enemy monster(s) picked is in the variable mv, which is defined at that point... so just change a_comm to mv and it should work as you intended. Speed is only checked when actions are slated / enqueued, they're sorted in a priority queue using the speed as priority and executed in that order.

It might be cleaner to add your speed variable to the case 30 block a bit further down, since that's where slated actions get finalized. There's a block here that lowers effective speed by -75% if the monster is paralyzed, and you could add in a new block that checks if the action type (battleaction_COMM_TYPE element of the array) is an attack, and if so, multiplies the SPEEDPRIO element with the move's speed. It shouldn't matter where you put this as long as it's before the "Finally, enqueue the action" bit, but it's probably safest to put it after the ailment block.

There's no built-in "buff user" special effect type, so you'd need to add a custom one. The current buff special effect is handled in obj_battlecontrol's Step event at line 735-743, you'd copy that block to a new case in the switch statement that begins at line 780 (where effects that affect the user are handled). Just replacing the movespfx_BUFF constant in your new copy with the new constant, and changing all instances of the target variable trg to a_user in the new copy should be enough to make the code work.

Once all that is in place, just set your move's special effect to your new movespfx_BUFFUSER (and include the stat and buff tier like the existing buffs/debuffs) and you're good to go!

The freeze seems to be because the menu is destroyed with the default cancel, which doesn't advance the cutscene you're in. can_destroy is turned off just to prevent this by default, but you could add it in as a separate destroy script as a failsafe:

In msh_spawn_namingmenu at line 10, insert a new line:

script_destroy = csc_proceed;

Also insert the same line at line 3 in cc_shrinerename.

Now the menus should proceed the cutscene even if destroyed early.

For back sprites, there's a macro mond_SPRITE_BATTLE in init_constants. You'll want to add a new mond_SPRITE_BACK macro with an unique value, go to init_monster and add a new line after line 5:

global.monster_data[argument0,mond_SPRITE_BACK]    = argument2[2];

Now go to init_monsters and add the back sprite to the array of sprites that get passed in for all monsters.

To actually read the battle sprite, I think the cleanest approach is to edit monster_get_battlesprite. Check if the AMP-ID passed in is in the "enemy" region ( >= AMP_FIRST_ENEMY), and if so return the mond_SPRITE_BATTLE sprite, otherwise return the mond_SPRITE_BACK sprite.

amp_has_monster just checks whether that AMP slot isn't empty. There's no script to check whether the player has a specific monster, so you'd need to make a new script with content along these lines:

///amp_player_owns_monster(monID)
//Returns true if the player owns at least 1 monster of the given species, false otherwise.
for(var c = AMP_FIRST_ACTIVE; c < AMP_FIRST_ACTIVE + PARTYSIZE_ACTIVE + PARTYSIZE_BOXED; c++){
    if(global.active_monster_party[c,amp_MONID] == argument0){
        return true;
    }
}
return false

On closer inspection, I just realized that this is a bug! The grass' drawing code uses || instead of && when doing the collision check, so essentially the player's status will always count as "in my particular patch of grass" and trigger the additional head drawing. Changing the the collision check ||s to && in obj_tallgrass_32's draw event (lines 13-16) should fix this. (obj_tallgrass_64 inherits everything from _32 so you shouldn't need to change that)