Home
Creators
Search Recent Random
Posts
Search DMs Popular Hash Lookup Tags Random
Importer
Import FAQ
Register Favorites Keys Review DMs Logout
Community
Telegram ThePornDude
Home Creators Posts Import Register Favorites Logout

[Starlight] Starting to look like a TBS! (Patreon)

Published:
2017-04-21 19:54:38
Imported:
2026-06
Tags:
haven't archived this post yet. have a subscription? use the importer!

Content

The previous disclaimer applies-- these are all placeholder graphics. In fact, most of them are just default RTP graphics. The point is that the move range thing exists and is working, and so is path-finding, and those were the main things I wasn't immediately sure how I would handle.

I'm not sure if it's coincidence or natural that the hardest parts of both the combat and the battle system were front-loaded, but whatever the case it only took me a handful of days to knock this one out! I'll explain how.

RPG Maker doesn't actually have any latent pathfinding function. Its options are usually to follow a specified route, which is balls if you're coming from or going to various places or if things might get in your way, or to do something generic like 'move towards player' and inevitably get stuck on the first rock they encounter.

Unlike older RPG Makers, RMMV uses script plugins... so I just went and pulled a pathfinding one that someone made. Easy peasy. With that, I can immediately direct any game character to any place or any unit on the map in one command or less. It cares about obstacles. It cares about people in its way. It's wonderful.
(an' lemme tell ya, I'm gonna be sorely missing that feature when I go back to eventing Reborn and having to account for step-by-step movement routes...)

The above map is something i made to test the pathfinding and make sure it had those key elements. Orange-haired gal is just a pathfinding bot.
"Go to spot 5,8, pathslave."
"Yes, mistress."

Then I took the pathfinding method and turned it inside out. We use a loop to check every tile on the map that is in natural range of the selected unit's move stat, and then check each of those tiles with our pathfinder to see if we can -actually- get to them in X moves or less, or if anything is in the way. I call this True Distance to a target. If the true distance is too far, we don't draw the tile. The surviving tiles are stuffed into an array, and then drawn on a cell-sprite layer that i carved out of RMMV's mouse support visuals.

I've tested this up to 15 move range which is frankly way more than we'll ever need, and it works like a charm-- shown above is 5. I have a few approaches to take to try and optimize the method, since I'm caring about lag from the get-go and there is a small half-second delay when using a huge range, but it's not really noticeable for moderate ones like the above. Still room for improvement. 

So how about the rest of this map? 

  • Mr. Kingy was a tool to test the True Distance checker in isolation, whereas the NPC  I click on tests it in context of selecting a target. 
  • Headband chick (who's sprite I made Ego out of) sets up the TBS scene and turns the player character into the cursor. 
  • The other two NPCs are bots to go into the Combat scene, which y'all have already scene.
  • The diamond shapes in particular were for me to see how the move-range dealio would respond to being trapped in an area. It gave me an infinite loop at first, then it lagged, then it was finding paths to spaces that didnt exist. Now it behaves. 

Next up-- structuring out the player/enemy turns. Nothin' to it, but to do it~


Files

Previews only

Comments

Therrester

Technical question: How do you obtain the tiles for the loop? Do you literally check every tile on the map (which presumably have an X/Y coordinate) and check to see if that tile is within range of the character's tile based on the character's movement speed? Because if so that's hugely inefficient. An alternate method would be to start from the character's position and check every adjacent tile. If that tile is moveable, add it to an array and mark it as length "1". After having all tiles within range of 1, go through the array and check each tile adjacent to the one you're currently checking (while ensuring that you're expanding outwards and not inwards). If that tile is moveable, check it as length "2" and add it to the array. Keep going until you've reached the maximum tile of length X and you'll have all the tiles you're character could move onto. Much faster than iterating each tile back to the character.

Michael Hamann

star light, star bright, another obstacle destroyed tonight! all the details to be worked on, so easily overlooked by someone who's not into development, heh. how about an easter egg of somebody bumping into a wall... :P ? P.S. the scene pun did not feel acceptable ^-^ I'm proud

Hachilio Murray
>>4807241

Then you add the "pathfinding" function. I don't know how efficient that is. If I had to go through all that work, I would save all those options going from 1-2-etc. I suppose data-wise, that could be a 3-dimensional array with each row a possible path, and each column a particle coordinate (2-D position). If a path is a dead (impossible) end, you just fill it with NaN's. Then you can make a matching array where each entry is the length (number of steps) to target. Then for the display (and execution), you just choose the option that gets to your target in the least amount of steps, according to that second variable. This way, it's even possible to accurately pre-define the size of the array. To reduce lag in this way, you can compute all these variables for each character at the start of the turn (while the screen indicates that it's now the player's or enemy's turn) and during each move by a character.