Now, for the room system. I'm gonna use pictures for this, because words just don't seem to cut it. :/
(http://img137.imageshack.us/img137/5828/multiplerooms1.png)
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.
(http://img255.imageshack.us/img255/3672/multiplerooms2.png)
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. 8)
Quite brilliant, if I do say so myself. 8)Geez. I wonder how many people have used this system. 9_9 (http://nifflas.ni2.se/forum/Smileys/Niffpack/tongue.gif)
either you need to make the view size correspond to GM's frozen zone (which is basically impossible)Err, no.
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.)
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 roomSee "inefficient."
-First of all, the player must be a persistent object.All of this is unnecessary with my method.
-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.
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.
Using multiple rooms is an inefficient system
Linking images is annoying and difficult
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.
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.
See above point on CPU and memory usage. This renders all arguments about increased resource usage moot.Using multiple rooms is an inefficient systemNot 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.
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.Linking images is annoying and difficultI'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.
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.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.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.
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.
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.
And when you get to the point where one area is 10+ rooms? Or you want to see how something looks as a whole?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.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.
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.
And when you get to the point where one area is 10+ rooms?
Or you want to see how something looks as a whole?
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.
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.
It's basically just a heck of a lot easier.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.
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.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.
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.
As far as keeping track of large areas, and all that...nobody said game making was easy, did they? :PAgreed. And if it is, you're probably doing something horribly, horribly wrong. ;)
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.when it was in fact you who said it. I accidentally quoted it, but removed the quote tags by mistake. X) My method was invented by me sometime last year; it's certainly not a common method. I just want that to be clear.
Well, I believe that the method described above dictates how the game engine would be.Oh, I'm sorry. I must have misread your previous post; I thought you were saying that a level editor is a good tool to design levels, not build the engine. My bad.
Minmay: Multiple 1-screen rooms
PYP: Large rooms with views
vdweller: 1 room, load data externally each time the screen changes
the character started a few too many pixels into the new room
If you can't figure out the code to do it with, then maybe the room system is better. Now that I think of it, my code may use more higher-level functions than the room system, making it less noob-friendly. On the other hand, if that explanation is insufficient, please tell me and I'll post a tutorial.
Actually, yours is probably easier to do in GM; all you need to do is use the view snap function. Just set its threshold to the same as its size.That would result in a standard moving view.
Actually, yours is probably easier to do in GM; all you need to do is use the view snap function. Just set its threshold to the same as its size.That would result in a standard moving view.
You centered the origin of the player's sprite, right? I think that may be the problem.Edit: YES! This works great! One thing that I noticed... if you go left, then the character appears half on and half off on the next screen, but when you go right, the character appears half his width into the screen... How would I make it so that the character doesn't do this?
Said option is in the room properties; no GML is required, though you could use the GML method detailed in your tutorial, as well. You could do it with drag and drop for that matter, but it would be kind of pointless.There is no option in the room properties to do this; I'm 100% confident of that, since I went and checked when I saw your previous post, and again when I saw this one. The only thing room properties can do is set the max step size, not the minimum step size or the only step size.
There is no option in the room properties to do this; I'm 100% confident of that, since I went and checked when I saw your previous post, and again when I saw this one. The only thing room properties can do is set the max step size, not the minimum step size or the only step size.
Strange...perhaps it's changed between GM6 and GM7? I guess that would make the room-changing method easier then.I'm fairly sure it wasn't even around in GM6, since I used that for about a year.
You should pretty much always store music externally due to its size, otherwise the game's preloading will be unbearably long. Graphics aren't as bad, but it would still be a good idea.Seconded, this is definitely best.
For saving the game, you should always make your own save format. It needn't be complex, just make sure the files it produces are small (and that it's fast). GM's built-in save format is horrible, terrible, bad, and I don't like it.Not to mention that if you release any update at all, previous saves won't work, since the game is actually saving the exact state and not a list of variables that can be transferred over to a newer version.