On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(1 edit)

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.
(+1)

Thanks so much for all the info! Looks like it should be manageable and a good place to get started.