Charas-Project

Game Creation => Requests => RPG Maker Programming => Topic started by: Donut on December 15, 2015, 02:29:49 PM

Title: Progressive MiniMap
Post by: Donut on December 15, 2015, 02:29:49 PM
Platform: RM2k3

Problem:
Hello dear fellows!

I'm trying to figure out how to make a progressive MiniMap. I know how to do a regular MiniMap (with a picture for the layout and one for the player), but I don't want the player to know about the entire map at the start. See it as Etrian Odyssey style: the player can only see in the MiniMap the squares he already visited. This would allow the player to spend less time between the floors of a dungeon if he wishes to start from the very beginning each time, AND this would allow me to make a NPC buying completed maps so that the player has a way to earn some money other than chests.
So I've figured a way, but it seems rather complicated and heavy:
- Make a normal MiniMap of the floor
- Cut it into the individual squares
- For each square, create an event on "Event Touch" which display the corresponding square image at the right (X,Y). Hence, when the player walks on a square, it gets displayed. But if the player does not step onto it, then it is not displayed.
This is really heavy, especially since my labyrinthe are made of LOADS of squares (I can easily get 200; meaning 200 images as well... Eurgh).
It gets even more complicated if I want to count to track the % of map completion or just to remember the state of the floor when the player goes somewhere else. If I increase a variable for counting by 1 each time the player steps onto a square, or if I want to keep track of which squares have been visited, then I'd have to create a switch or stg of the kind to track that this square should not be counted twice.
It'd be easier on RMXP since it has the local switches, but RM2k3 does not have such a thing at my knowledge.

Do you see any other alternative I could try? I've been thinking about it for 2 days now and I don't see any, but maybe I think too much and something very simple can be made about it.

Thank you =)
Title: Re: Progressive MiniMap
Post by: Prpl_Mage on December 15, 2015, 04:29:33 PM
I think you are right about needing a whole lot of pictures. But will the dungeons be randomly generated or not? That could cut down the work a little at least.

Instead of increasing the variable by 1 for each step you could make it so that when the picture is displayed the first time it adds 1, that way it shouldn't trigger twice. But it depends largely on your other code.

I'll give this some thought, right now I'm thinking that you could at least reduce the rows of code needed if you use variable references...

Okay, so if you have 200 different pieces of a dungeon, how exactly is the game keeping track of that? because this could most likely be done in relation to that. The biggest issue right now is that we would require a variable for each tile without variable references.
Title: Re: Progressive MiniMap
Post by: Donut on December 16, 2015, 01:07:29 PM
I think you are right about needing a whole lot of pictures. But will the dungeons be randomly generated or not? That could cut down the work a little at least.

No they are not randomly generated. So that I can work on proper level design.

Instead of increasing the variable by 1 for each step you could make it so that when the picture is displayed the first time it adds 1, that way it shouldn't trigger twice. But it depends largely on your other code.
Hmmm... but how do I check if the picture is displayed? I don't see any conditionnal branch that does it, so apart from a switch or something similar, I fail to see how this is possible. Moreover, If I teleport to another map, I won't have a "memory" of it.



I'll give this some thought, right now I'm thinking that you could at least reduce the rows of code needed if you use variable references...
I thougt so too, but I'm not sure it's doable with variable references :/


Okay, so if you have 200 different pieces of a dungeon, how exactly is the game keeping track of that? because this could most likely be done in relation to that. The biggest issue right now is that we would require a variable for each tile without variable references.
I don't quite understand what you mean. Are you asking me how I can know how many squares there are (that can be done easily through scanning the entire map, checking the terrain ID - it's currently not done though)? Your last sentence is basically what I'm afraid. I gave 200 as a number, but my biggest floor have more than that easily. If I have to create a variable/switch for each of them... I'm not saying it's not possible, but it will be a pain in the ***.  And I'd like a better and proper way to do that, but each of the one I've considered are no better (they are even worse).

I thought I could do something on the order of terrain ID once more on the train just now, since I created the FP-view using Terrain ID. Apparently, exposing problems to people makes you already think more efficiently^^
So say that the walkable areas can be ID 1 or 2. Set all of them at 2 at the beginning and then when you walk on them:
1) If ID=2 add 1 to a variable, display image and change the tile to ID=1
2) If ID=1 then only display image
Problem is: if I teleport on another map, I loose the changes of tiles. Other problem, if I use the "change tile" it changes all the same tiles at the same time. I could deal with that last problem if I use dummy tiles, but it might be heavy as well (and I don't think I've got enough space in the chipset).


EDIT

So I counted, just to know how much I got to do if I do it the hard way since I still haven't found a suitable alternative - I counted walkable areas, so the numbers are without walls.

I have 870 picture slots available (the others are used).
Floor 1 is made of 325 squares.
Floor 2 = 312
Floor 3 = 366
Floor 4 = 465
Floor 5 = 454
Floor 6 = 785
Floor 7 = 700
Floor 8 = 487
Floor 9 = 706
Floor 10 = 227
Floor 11 = 47
Total =  4874

SO doing it the hard way would require 4874 switches (2k3 can go to 9999, I use only 100); maximum 785 pictures.
It's do-able, not practical, but do-able.