7 replies to this topic

[pwyskowski]

• Title: Room Exit / Warp Exit Example
• Description: Tutorial on Directional and Warp type room exits.
• GM Version: GM8.1 and GM8.0
• Registered: No
• File Type: .gm81, .gmk, .zip
• File Size: 101kb
• File Link: ZIP File
• Required Extensions: n/a
• Required DLLs: n/a

Summary
This tutorial shows an example of making exits/warps to move between rooms in a top down Adventure/RPG style game.

Edited by pwyskowski, 14 December 2012 - 01:42 AM.

[DakotaBonez]

This is exactly what Ive been looking for!
A way to Connect rooms like on that atari 2600 game Adventure.
Thankyou so much!

[pwyskowski]

You're welcome.

I'm glad that someone was able to get some use out of this.

[Nathaniel]

perfect! thanks

[pwyskowski]

Added a .gmk to the zip file today for you GM 8.0 users.

[Tarik]

Hehe, if people would read the manual sometime, it's litterly just setting the transition kind and changing rooms.

Either way, nice example. A quick note about 'var', you used it in the exit objects. However you can't initialize a variable to be temporary in the create event, and then use it in a collision event. You can, but it doesn't retain it's temporary status, it just becomes a local variable. If you want the variable to be temporary, you'd have to call var MyWarpRoom in the create event. But then, if you'd actually use 'var' in that way, it would prompt errors because you're not using it as a temporary variable in the collision code, you're using it as a local variable to store the room to warp to from the start of each room.

Just calling
variablename = 10; is entirely possible in GM. This is a local variable, local to the instance who created it, it's destroyed if the instance is destroyed that holds it.

If you call in *in the same script* before this:
var variablename; it becomes a temporary variable, which means at the end of the script or piece of code, it's removed. This means you don't want to use these for MyWarpRoom. It means something like this:

var variablename;
variablename = 10
with(anotherobject)
{
myvariable = other.variablename
}

Gives an error, as variablename is temporary and can't be called by other objects.

Temporary variables are usually entirely unnecessary. If you clean up your instances, you clean up your local variables. Other than that, a local variable takes 8 bytes. That means you can store 130.000 of them in a single megabyte of RAM, and most computers have thousands of megabytes of ram. Unless you do a lot of processing of temporary databases and such, it's not really worth using most of the time. I still do, but it doesn't make much sense haha. Oh, temporary variables are also slightly faster, but as calling a variable is about the fastest function GM has, it's an unnoticeable speed increase for all but a few purposes.

Nice example, best wishes,
Tarik

[juegosisa12]

I liked
very good
still so

[xepicmanx]

Very nice example! 

 

What I would do instead of simply creating a new instance of the object player in the new room, is mark the player as persistent and then set its coordinates to that new position, around whichever door it led to, using the room's creation code. The only reason I say this is because I can imagine those of you who want to make a zelda-ish type of game will run into problems when your player's code is initialized every room change. This way, you can keep those variables and it smoothly transitions.