Yal's Monster Collector Engine

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)

Evolutions transcendences are defined at Scripts-->Data Mangling-->Database Setup-->Init Monsters, if you scroll to the right a whole bit you'll see this data:

(Basically it's an array of 3-member arrays, which represent the way to evolve, what thing triggers the evolution, and what monster to evolve to. For level evolutions, the trigger is the level to evolve at, for item evolutions it'd be the item ID, and so on... I'm unsure if I ever made item evolutions)

amp_clear_monster deletes a monster from the Active Monster Party (which is the big array that has all the monsters the player owns, including the storage boxes). Then you could use amp_generate_monster to create a new monster on the same AMP-ID, so it takes the exact slot the traded monster occupied. (Actually, you could just amp_generate_monster onto that slot directly, it clears the data with amp_clear_monster first). Once the monster is generated, you can manually apply unique quirks you want the traded monster to have (e.g. special moves or held items).

To get the AMP-ID of the monster to trade, I'd spawn a menu using msh_spawn_monster_list (which spawns a list of the monsters in the active party) which has a new "trade offer" menu event... it'd check if the monster in that slot matches what the NPC wants (that data would be stored in some global variables in the cutscene initialization script with the conversation) and if so, asks you a "ok?" question with msh_areyousure, and its OK script initiates the trade (sets the appropriate "trade done" flag, loads a different room with the trade animation, and then goes back).

If you need to familiarize yourself with how to carry data around, starting from mev_pause_monsters and looking into how the menus read party data further down the line should give you a good starting point in figuring out how to handle the AMP data (and the menu system in general).

Changing resolution should be fairly trivial, the battle controller sets things up based on the room size and most menus are defined in terms of two constants VIEW_W / VIEW_H. You'll need to manually change room sizes / viewports of every room in the game, but there's just a handful of rooms so it's hopefully not too much work.

Overworld character speed is defined in pixels per step, but it's just one variable you need to change in the player's create event. You might potentially also want to change the TILESIZE constant if you change the tileset size (this will have some ripple effects like grid sizes in existing rooms also having a different size, but I've never really tried changing a tileset size so I'm not 100% sure how much of that is automated)

Attack animations uses any object you want (typically a child of the effect parent), the battle flow waits until all effects are gone before proceeding. There's a convenience script fx_deferred_projectile which lets you spawn a standard projectile which runs another script on-hit (which works for a wide range of attacks) but you can add as intricate effects as you want if you feel like it.

The movement system isn't grid-based, but it shouldn't be too hard to add in. You'd basically turn the overworld player into a state machine with two states (idle and walking): in idle state, if any movement key is pressed, if whatever's one tile in that direction is OK to stand on: switch to walking state, start a countdown of TILESIZE, and start moving in that direction. In walking state, reduce the countdown, and when it hits zero, stop moving and switch back to idle state.

Thanks, glad you like it! ^__^

Monster storage system basically uses the gen3 system where you pick up monsters and move them around between boxes and the party. (Monsters caught when your party is full automatically is sent to storage). There's no item storage system, but you have infinite inventory space so that shouldn't matter (it's just more convenient now when you instantly have access to every item you own anyway).