10 replies to this topic

[pmposse]

I've trawled the forums but can't find an answer for this; I'm making an exploration game and am having a problem getting my head around this:

I need to be able to show if a room has ever been visited, so in my HUD a list of rooms would have [unexplored] next to the name until the room had been visited and then, forevermore show [explored] (or some other info).

Anyone have any ideas how this might be implemented?

Ta

[annihilator127]

Hi pmposse!
You could use a global array. Something like

if (global.visited[room1])

The problem with that idea is that it wastes memory if you deleted a lot of rooms, and initialisation is tricky because the domain varies as you add more rooms.

Or, set a room to persistent once you visit it, and check it with room_get_persistent(room1).

Hope this helps!

[Jack Indie Box]

i like the room_get_persistent(room1) idea

but what about a ds_list ? thats how i would do it

[PetzI]

You could use a ds_list or a ds_map if you have the paid/Standard/Pro version of Game Maker. In the Help file, read the chapter under The Game Maker Language (GML) > Data Structures. Basically, they're really handy ways to organize and manipulate data. I can get into more detail if you want.

By the way, wouldn't it be nicer to just have the room's name me a different color or marked with an asterisk or something instead of a bulky "[unexplored]" next to it? Or maybe an "[E]" next to the explored ones.

[kburkhart84]

I would use a DS_MAP because instead of simple indices, you can use the actual room name for access, because each index is both a "key" and a "value". The "key" would be the room name, and the "value" would be true/false for if you have visited. Then, upon entering a room(or leaving it) you set the value to true.

You could also use a ds_list, but then you'll have to organize yourself to remember for sure which index is which room. With either one, you have advantages over arrays. They come with each "serializing" functions that basically turn the structures into a single string, which can then be saved into a file, either ini or your own text file format, and then easily loaded back in later. This trick is surely the easiest way to get things to/from variables and save files. In fact, I use it to store my input configurations in my kbinput3 extension. It would also be useful to have player options in such a structure, like sound volumes, fullscreen mode, difficulty levels, whatever settings you have that you want to save, and then just use that simple string to save it. And you also get the advantage that the string is in no way easily readable by a player. Even if they open the text file, they can see the string, but it is a long something that looks like garbage."asdfofgbroijgoadjflksjvoajserkjasdhfoaied", and though in theory the "code" could be cracked, it isn't worth it for most players.

[TheouAegis]

The array method isn't bad. The only problem with it are the intro screens and any cutscene/transitional rooms. They would take up additional memory if not handled properly.

The key to making the array work is to have all the rooms in order. Not in the order they're visited, but in a specific order. Personally, if I was doing something like this, I would arrange the rooms in this order:


Loader Room (this is the room you set all your global variables in and do any fancy stuff you need done before the game starts)
Level 1
Level 2
Level 3
Level 4
....
Level N
Title Screen
Instruction Screen
Game Over Screen
Demo Room 1
Demo Room 2 (Demos just being what I call eye-catches)

Now most people reading this are thinking, "That won't change anything because room ID isn't based on the room's order the list." Well, they're right and wrong at the same time. True, just reordering your rooms won't change anything. However, if you export all the resources of your game and then import the .gmres file into a new, clean game (go to the File menu and create a New project), the rooms will be imported in the same order you had them organized before but with the correct IDs as well.


Or at least I think it does that for rooms too. I verified it did it with objects and sprites.

[kburkhart84]

I don't agree with the above post. It depends on something that could very well change at any time(an undocumented feature) and also, the would be memory savings is very little. Also, by using a ds_map you can have only the needed amount of indices, with each index being a level's room index, and not all rooms will be taking up space, so you aren't overusing the memory.

I'm not saying you couldn't do this with a regular array, but the ds_map structure provides so much of an advantage, with using indices based off of room names if you choose, and the string serialization for easy save/load to files, why use simple arrays. An exception to this would be an extremely intensive need, as in something that has to be extremely fast. But this case is far from that.

[TheouAegis]

if visited[Stage_1a] = 1
{
room_goto(Stage_1b)
}


I'm not understanding what you mean by indices based off of room names. The code I just posted sets the index based on the room name.

And a feature that may be removed? Why would Yoyo Games remove the resource export/import feature? It's a fundamental part of GM. It's what makes games with multiple designers possible. Of all the features in GM, the resource importer is not on my forseeable list of features to be removed in later versions. As it is, you shouldn't be relying on room names anyway because all the room name is is just a mnemonic for the room ID number.

Edited by TheouAegis, 16 May 2012 - 01:07 AM.

[pmposse]

You could use a ds_list or a ds_map if you have the paid/Standard/Pro version of Game Maker. In the Help file, read the chapter under The Game Maker Language (GML) > Data Structures. Basically, they're really handy ways to organize and manipulate data. I can get into more detail if you want.

By the way, wouldn't it be nicer to just have the room's name me a different color or marked with an asterisk or something instead of a bulky "[unexplored]" next to it? Or maybe an "[E]" next to the explored ones.

Thanks all for your replies, Petzl, the ds_map seems to be the way to go and looks like I'll need it in the future for inventory etc too, is there any chance you can go into more detail, I've looked at the manual etc but can't seem to see a 'starting guide' type thing.

With regards the actual drawing of the visited/not visited I've not settled on how to display it yet, infact the majority of my game so far is rubbishy hand drawn and labled, thought I'd best try to get the mechanics working before I spent time prettying it up!

thanks.

[kburkhart84]

if visited[Stage_1a] = 1
{
room_goto(Stage_1b)
}


I'm not understanding what you mean by indices based off of room names. The code I just posted sets the index based on the room name.

And a feature that may be removed? Why would Yoyo Games remove the resource export/import feature? It's a fundamental part of GM. It's what makes games with multiple designers possible. Of all the features in GM, the resource importer is not on my forseeable list of features to be removed in later versions. As it is, you shouldn't be relying on room names anyway because all the room name is is just a mnemonic for the room ID number.

Actually, the feature I'm talking about isn't the resource loading, rather the room names being in a simple numbered order(1, 2, 3). When/If they change that into something like pointers, or anything else they decide, you can no longer create array indices from that, because you risk creating an array that is too big, and only using that first index, even though all the rest are allocated. Using a ds_map, you only get one index per allocated value, regardless of what the index actually is. In fact, if they were turned to strings, it would still work, or anything else for that matter. And, there is no wasted space. The thing is that you can't depend on room indices staying the way they are now. Eventually things are going to be actual compiled code, and even the current version of GMStudio already does things differently. So you can't depend on it to stay the same.

Actually, if I'm not mistaken, the resource loading thing is not going to be the same either, considering GMStudio uses separate files for all of the resources.

[TheouAegis]

Simple solution: stick with GM 8.