Does anyone use Game Maker?

If so, just a quick question:

If I wanted to make a knytt like game on game maker where the character explores the world, how would I connect all the rooms up into one BIG world? I have the latest version of gamer maker and have upgraded to pro. Any help appreciated.

Well, I use MMF, but there are a few ways to do this:

1. Create a giant map and have the scrolling snap to the nearest screen. (Used in Knytt)
2. Create multiple screens, and assign each an x and y position. Then, have the game move to a different on based on position. (Similar to KS technique)

Woo! I have the perfect solution for this. Here's a PM I sent to someone else explaining how it works:

Now, for the room system. I'm gonna use pictures for this, because words just don't seem to cut it.


This is how a room might start out. The entire area is in the room, but the player only sees what's inside the grid box marked "View 0." In addition, every instance outside that box is deactivated, which lets the game run at a good FPS.


In this image, the player has left the previous grid box via the right side. Thus, the box to the right is now shown in View 0, and instances inside of it are activated.

Whenever the player leaves a screen, the view shifts over in the direction they left it by a fixed amount. Quite brilliant, if I do say so myself.

You make the entire area in one room (or into 2 or 3, if that makes things easier). Then you program the view to follow the player, but only if they leave the view. So if the player is not in View 0, and is, rather, to the right of it, then View 0 should move to the right (in steps equal to its width) until the player is within it.

Did that make any sense?

Quite brilliant, if I do say so myself.

Geez. I wonder how many people have used this system.  

I'm afraid that Purple Pineapple didn't really say anything, and PYP's method is just dumb - either you need to make the view size correspond to GM's frozen zone (which is basically impossible), or you need to code everything specifically so it deactivates when outside the view (which is annoying and will make your game run poorly).

The proper method is indeed to make each room one room, and use the following logic in your code:
-First of all, the player must be a persistent object.
-When the player exits the screen, decrease mapx by 1 if they went off the left side, increase it by 1 if they went of the right side, decrease mapy by 1 if they went off the top, increase it by 1 if they went off the bottom.  You could reverse these or use different variable names, of course.
-Also set the player's X or Y position to be at the right edge if they went off the left, at the top if they went off the bottom, etc.
-Name all your rooms to correspond to their positions on your map.  If room 50_50 is the starting point, then room 51_50 would be the room to the right of it, and so on.  (Again, you can reverse these.)
-Whenever the player leaves a room, a script should execute that places them in the appropriate room based on the value of the mapx and mapy variables.

It really is very simple.

either you need to make the view size correspond to GM's frozen zone (which is basically impossible)

Err, no.
The instance_activate_region() and such functions are pretty easy to use, just supply the view top x coord, view width, etc as arguments. All in one room is much more convenient when level designing, too, so I'm really not sure why you'd want to split it all into smaller rooms.
Edit:
instance_activate_all();
instance_deactivate_region(view_xview[0],view_yview[0],view_wview[0],view_hview[0],false,true);
(This may seem wrong, but note the 'false'- that inverts the effect, disabling everything NOT in the region.)

@minmay: Using multiple rooms is an inefficient system, and I find it bothersome that everyone insists on using it regardless. Linking images is annoying and difficult, moving from room to room is slower than moving about within the same room, and programming objects to affect objects outside the same room (e.g. a button on screen 30x47 that opens a door on screen 30x49) is far more touchy.

I'm afraid that Purple Pineapple didn't really say anything, and PYP's method is just dumb - either you need to make the view size correspond to GM's frozen zone (which is basically impossible), or you need to code everything specifically so it deactivates when outside the view (which is annoying and will make your game run poorly).

Nope. Just use the code that Dataflashbot used; it's basically what I did.

The proper method is indeed to make each room one room

See "inefficient."

-First of all, the player must be a persistent object.
-When the player exits the screen, decrease mapx by 1 if they went off the left side, increase it by 1 if they went of the right side, decrease mapy by 1 if they went off the top, increase it by 1 if they went off the bottom.  You could reverse these or use different variable names, of course.
-Also set the player's X or Y position to be at the right edge if they went off the left, at the top if they went off the bottom, etc.
-Name all your rooms to correspond to their positions on your map.  If room 50_50 is the starting point, then room 51_50 would be the room to the right of it, and so on.  (Again, you can reverse these.)
-Whenever the player leaves a room, a script should execute that places them in the appropriate room based on the value of the mapx and mapy variables.

All of this is unnecessary with my method.

The instance_activate_region() and such functions are pretty easy to use, just supply the view top x coord, view width, etc as arguments. All in one room is much more convenient when level designing, too, so I'm really not sure why you'd want to split it all into smaller rooms.

Unfortunately, those functions don't work the same way the frozen zone does.  And, perhaps more importantly, they're slow.  (Of course, everything in GM is slow, but this in particular will get really bad if you have a lot of objects.  Perhaps, for this particular game, in which there would probably be only a few objects per screen, it would be fine, but in general I wouldn't recommend it.)

Using multiple rooms is an inefficient system

Not really.  It's a bit more difficult for the game's creator, but it's far more efficient in terms of resources.  Although the room-to-room transitions will be slower than simply moving the view, you'll save a lot on both memory and CPU usage.

Linking images is annoying and difficult

I'm assuming you mean making the room edges match up?  You'll have that problem regardless of the system you use, I'm afraid.  Using the view method will make it slightly more convenient if you're using tiles, but only slightly.

programming objects to affect objects outside the same room (e.g. a button on screen 30x47 that opens a door on screen 30x49) is far more touchy.

This is true.  Certainly, if you want an enemy or something to continue running around even when you're not in its "room," then the view method would be preferable.  But since you mentioned deactivating instances outside the view, it really does make more sense to use the room system.



It should be pointed out that the whole efficiency thing might be moot, making the view method just fine, depending on how simple the game is.  Certainly, if you're simply using a few tilesets like in Knytt to design the screens, and gradients for the backgrounds, that's fine.

But a game with similar room changing - An Untitled Story - could never hope to do this.  Every screen has a PNG background and foreground image, both 640x480.  The PNG compression keeps them small enough on your hard drive, but they obviously need to be uncompressed to be displayed.  If it used your view system, most home computers wouldn't be able to run it because of the massive memory usage.

Unfortunately, those functions don't work the same way the frozen zone does.  And, perhaps more importantly, they're slow.  (Of course, everything in GM is slow, but this in particular will get really bad if you have a lot of objects.  Perhaps, for this particular game, in which there would probably be only a few objects per screen, it would be fine, but in general I wouldn't recommend it.)

Wrong. The function runs as fast as if you had only the activated instances in the room; this is because GM activates all the instances, which just means that it will execute their events when it comes to them; it already knows where they all are, which is just variable storing and takes virtually no CPU. But then instances that aren't in the view are deactivated, and their events are never executed, so it's as if they were never activated in the first place.

Quote from: Pick Yer Poison on August 31, 2009, 18:43:19

Using multiple rooms is an inefficient system

Not really.  It's a bit more difficult for the game's creator, but it's far more efficient in terms of resources.  Although the room-to-room transitions will be slower than simply moving the view, you'll save a lot on both memory and CPU usage.

See above point on CPU and memory usage. This renders all arguments about increased resource usage moot.

Quote from: Pick Yer Poison on August 31, 2009, 18:43:19

Linking images is annoying and difficult

I'm assuming you mean making the room edges match up?  You'll have that problem regardless of the system you use, I'm afraid.  Using the view method will make it slightly more convenient if you're using tiles, but only slightly.

Yes, I do mean that. And the view system makes it extremely simple, since the entire area is visible at once in the editor. And that applies not only to tiles, but also to objects.

Quote from: Pick Yer Poison on August 31, 2009, 18:43:19

programming objects to affect objects outside the same room (e.g. a button on screen 30x47 that opens a door on screen 30x49) is far more touchy.

This is true.  Certainly, if you want an enemy or something to continue running around even when you're not in its "room," then the view method would be preferable.  But since you mentioned deactivating instances outside the view, it really does make more sense to use the room system.

There's a simple solution to this: instance_activate_object(obj). This activates all instances of a specific object. So when you hit the button to open the door, activate all instances of the door, open them, and then deactivate them. They're now open, but deactivated. Or for an enemy that chases you from screen to screen, simply activate all the objects on the screen that the enemy is on as well using instance_activate_region(left,top,width,height,outside). Easy as pie.

It should be pointed out that the whole efficiency thing might be moot, making the view method just fine, depending on how simple the game is.  Certainly, if you're simply using a few tilesets like in Knytt to design the screens, and gradients for the backgrounds, that's fine.

But a game with similar room changing - An Untitled Story - could never hope to do this.  Every screen has a PNG background and foreground image, both 640x480.  The PNG compression keeps them small enough on your hard drive, but they obviously need to be uncompressed to be displayed.  If it used your view system, most home computers wouldn't be able to run it because of the massive memory usage.

Please don't do that. Trying to replace any game's way of doing something integral to the gameplay with a different method will only result in loads of fatal errors. You'd have to completely redesign AUS in order to make it work with my view system.

By the way, I think this is how Nifflas did it in wadf.

Please don't do that. Trying to replace any game's way of doing something integral to the gameplay with a different method will only result in loads of fatal errors. You'd have to completely redesign AUS in order to make it work with my view system.

I wasn't referring to AUS specifically; rather, to any game that uses many background/foreground images instead of tiles.

As far as performance...well, I guess I was wrong about that, then.

And the view system makes it extremely simple, since the entire area is visible at once in the editor. And that applies not only to tiles, but also to objects.

It applies to everything, but the fact is, it's only a slight increase in convenience.  Why not just open both rooms at once?



But my point remains: this view method will only work on the small scale.  To use it on a larger scale, you need to break it up into individual rooms, which, in addition to being clunky, sort of defeats the purpose.

Quote from: Pick Yer Poison on August 31, 2009, 20:47:43

And the view system makes it extremely simple, since the entire area is visible at once in the editor. And that applies not only to tiles, but also to objects.

It applies to everything, but the fact is, it's only a slight increase in convenience.  Why not just open both rooms at once?

And when you get to the point where one area is 10+ rooms? Or you want to see how something looks as a whole?

But my point remains: this view method will only work on the small scale.  To use it on a larger scale, you need to break it up into individual rooms, which, in addition to being clunky, sort of defeats the purpose.

When you say "small scale," how small are we talking? Because me and a few other Nifforumers are creating WaDF 2 in GM. So far we've made Hahara Mountains (as a test) and most of the intro stage. It uses this system. And it works wonderfully. But the way it works has each stage split into a separate room, which consists of all the screens you see in the game put together, so if that's what you're talking about, let me tell you from experience: it is by no means clunky, and it means having a fraction of the rooms you would if you used the separate room method.

tl;dr, but minmay's method is incredibly tedious and difficult to use. Should really only use with level editors.

When you say "small scale," how small are we talking? Because me and a few other Nifforumers are creating WaDF 2 in GM. So far we've made Hahara Mountains (as a test) and most of the intro stage. It uses this system. And it works wonderfully. But the way it works has each stage split into a separate room, which consists of all the screens you see in the game put together, so if that's what you're talking about, let me tell you from experience: it is by no means clunky, and it means having a fraction of the rooms you would if you used the separate room method.

I'd consider that pretty small scale.  You're looking at less than 30 rooms per area, and those use tiles instead of images (hence less memory usage).  The areas in WaDF and presumably your WaDF2 remake are connected in a very seamed, definitive way; there are loading screens between them and everything.  In, again, Untitled, there are some several hundred rooms, and while the areas are defined, they overlap a lot.  There is no way you could use your method; to have the entire map as one room would go beyond GM's capabilities and those of the average home computer, and to load screens one area at a time would introduce large pauses for loading time - which would be horribly jarring, given how frequently one travels between the areas in AUS.

Also, my method (to be honest, it's not my method, just one of a few common ones) is really very easy to use.  Perhaps I didn't explain it flawlessly, but anyone with even basic programming experience would find it very easy to implement.



So, once again, it comes down to this: it depends on the game, and "my" method is more universally applicable, even if it isn't always the best choice.

And when you get to the point where one area is 10+ rooms?

I honestly don't see why things would get hard to manage with large areas.  Keep notes if you have to.  I've done this; it never struck me as being particularily confusing.

Or you want to see how something looks as a whole?

That's when one would normally test the game, no?  Honestly, is there a game design tool in existence that uses an editor that will actually give you an accurate idea of what things will look like in the game?  I don't know of one.

I'd consider that pretty small scale.  You're looking at less than 30 rooms per area, and those use tiles instead of images (hence less memory usage).  The areas in WaDF and presumably your WaDF2 remake are connected in a very seamed, definitive way; there are loading screens between them and everything.  In, again, Untitled, there are some several hundred rooms, and while the areas are defined, they overlap a lot.  There is no way you could use your method; to have the entire map as one room would go beyond GM's capabilities and those of the average home computer, and to load screens one area at a time would introduce large pauses for loading time - which would be horribly jarring, given how frequently one travels between the areas in AUS.

Alright, I'll concede that point.

Also, my method (to be honest, it's not my method, just one of a few common ones) is really very easy to use.  Perhaps I didn't explain it flawlessly, but anyone with even basic programming experience would find it very easy to implement.
NINJA EDIT: Sorry, I accidentally quoted this from minmay and removed the quote tags by mistake. It shouldn't be here.

So, once again, it comes down to this: it depends on the game, and "my" method is more universally applicable, even if it isn't always the best choice.

I'll concede this as well. It's a good point, and I can agree with it.

Quote from: Pick Yer Poison on September 01, 2009, 01:09:03

And when you get to the point where one area is 10+ rooms?

I honestly don't see why things would get hard to manage with large areas.  Keep notes if you have to.  I've done this; it never struck me as being particularly confusing.

It's basically just a heck of a lot easier.

Quote from: Pick Yer Poison on September 01, 2009, 01:09:03

Or you want to see how something looks as a whole?

That's when one would normally test the game, no?  Honestly, is there a game design tool in existence that uses an editor that will actually give you an accurate idea of what things will look like in the game?  I don't know of one.

And get to the place you need to see, not to mention all the areas you want to check? Or what if you need to check if a line that begins in screen 34x97 is still on the same horizontal level on screen 40x97? If the player doesn't stay on the same horizontal screen path the entire time, that might be tricky.