Welcome to the wonderful world of RGSS3: Adventures With A Mini-Map Script

I recently finished a collection of world maps/designs to a point. These maps would appear on a location screen which I have yet to code, but they also served to get an idea of the layout of those worlds and plan things around them.

These are things that I should probably have done earlier, but I am focusing more on the experience or gameplay at the moment more than the story. That's a good thing, isn't it?

After drawing out those maps, I came to one underdeveloped world concept that I wasn't sure I could actually give an "overworld map" to speak of. If this world features at all in Witness To Unity, it might be a pretty small area that relies on the dungeon-view map screen for navigation instead.

This somehow lead to the grand experience of taking Tomy's Minimap script and turning it into a standalone map screen, two days of fun and frustration.

Everything seems perfectly okay to start off with, right? I find that maybe I should instead have the map centred and player position relative to that, instead of the other way around. I'm not sure which setup I want to use, so I have either one an option to start off with.

... what the hell is going on here? Does RMVXAce only load a portion of map data at a time to reduce lag? I haven't a clue why that's happening and at this point, I was focused on dealing with other elements for the time being.

I tried copying the cursor style from another element (or two) of the game, but I don't think this works so well. Which is a shame, because I really like UI consistency. If something can be reused or can flow in a similar way, it's better than whole new designs or graphics.

What I was struggling with early on at this point was getting the full map to centre correctly. The way Tomy's script draws the map is a little more than strange to me, but it is efficient. (Well, I guess.) I would have drawn the whole map and altered the origin point to display the location, or something to that extent. I wouldn't have done anything, I don't think I'm enough of an experienced scripter to create something like this from scratch.

The map icons like player location were ... kind of misaligned. I got to fixing them too, giving them alternate conditions similar to the numeric used to align the map. Just to make things more confusing, the player icon appeared to be screen relative, but the other icons are map-area-relative. Given the script's origin as a mini-map it doesn't make much sense, I probably goofed somewhere.

At some point this mysterious issue rears its head again. I discover that sometimes walking into the area doesn't always load the passability data. Sometimes it requires going into another map, and re-entering after the map viewer mode has been switched to full zoom.

Why would this be? It's something to do with the way the map is drawn, perhaps. Because the zoomed mode only draws the area around the player location, it doesn't show up when zoomed out. Why wouldn't it reload when it zoomed out? There are loads of elements to the script that refer to passability and draw dimension ranges, and no matter what I tried, none of them seemed to work for me.

Is it update_draw_range? No that doesn't seem to help. Is it update_around_passage_table? Nope, don't know what made me think that... What if I made in_draw_range?(x, y) instead refer to in_map_range?(x, y)? Nothing seemed to happen. Is it buried somewhere in draw_map_foreground(bitmap), the thing which draws the map itself? I spent some time breaking things more, but it refused to budge beyond that particular barrier.

It's get_passage_table_cache! By setting CACHE_NUM to 0, the entire map was reloaded instead of from this cache it created. CACHE_NUM would store and reload visited maps so as to speed up load. This would explain why going to another map was sometimes required, and sometimes didn't work at all, as I repeatedly messed with this value between 1 and 10. (There's another goof.)


Here I was creating a function to zoom the full map view at different levels. It wouldn't make much sense for a small map to be zoomed out at the same level as a large map, so I created a few pre-set sizes for certain map height ranges. It wasn't the dynamic resizing I would've liked, but it works. Dynamic resizing would perhaps have been a pain to balance anyway, as I would be using a lot of blank space in maps to keep the screen centred.

Why was this happening? I spent a lot of time once again going through whatever I could find talking about the cache, draw areas, ranges, anything. This time, no matter what I did I couldn't get the whole map to show up - only if I was zoomed in on that area, or if I edited the code to use the old zoom once again.

... did... did I fix it...?

... I fixed it. \ ; w;/

It turned out to be this bit of code in scan_passage(x, y):

rx = (dx * @draw_grid_num.x)...((dx + 1) * @draw_grid_num.x)
ry = (dy * @draw_grid_num.y)...((dy + 1) * @draw_grid_num.y)

I honestly have no clue what's going on here. I was too tired, am too tired, to process what I am looking at. All I know is that it's specifying the range of the map to draw, and that's not all of it.

rx = 0...$game_map.width
ry = 0...$game_map.height

That would be this instead. I made this the definitions for rx/ry when the screen was in full view mode, just as there were custom conditions for other elements.

Was this the problem I was having the whole time? Did I need to change the cache or the refresh behaviour? I could probably go back and deal with that*, but for the meantime I didn't want to break what seemed to be finally, consistently fixed. I moved on to other elements of this system.

*2014/01/05 EDIT: CACHE_NUM still needs to be 0 because of it caching map segments and refreshing instead of reloading when pressing the zoom key does not seem to work, I probably broke it. The transition of screen reload looks better any way.

I started working on graphics for icons on the map. Of all the heavy modifications, this might've been the easiest after the earlier experiences. While there was a bit of a muddle with creating a new format for event comments to refer to certain icons, that was just an oversight with me not reading what I copy-paste. Getting icons to centre over their locations and stay one size, instead of scale to the current zoom, was easy compared to strangling the map drawing ranges.

While it might not be terribly useful in a standalone map, more applicable to a minimap, I discovered I was able to make chasing enemies light up/use a different graphic, so I just went and did it. Perhaps if I haven't broken the script entirely, I'll re-implement this script as a minimap so those indicators would be more useful. This whole thing was inspired by Persona/Megaten games (and of course that world in WTU that might need it), and they use both a map screen and a minimap.

I later decided anti-aliased icons weren't working out and went with pixel-sharp graphics. More UI consistency, like a recurring palette, at hand here too. I'm not sure if this is everything I'll need, but I don't want to fill up any given map with icons either, or give the player too many symbols to memorise. (Persona 1 and 2 on the PSP provided a legend for their dozen or so symbols, and I think this was a bad design choice.)


Where was I? I am glad I have a to-do list that covers what I need to do next or what is in progress, or I'd end up with all these hanging threads and a broken, confusing looking project. I mean, this need to create this map system should've come later, not because I needed something to provide maps for areas I've yet create.

I haven't even created the screen for the overworld maps I drew, the ones I talked about at the start of this mess. That's for another time. I have weapons and weapon animations I should be doing. ... or sleep. Sleep sounds nice too.

Saturday, 4th January 02014

blog, games, programming, witness to unity.