ENIGMA Forums

Contributing to ENIGMA => Proposals => Topic started by: Josh @ Dreamland on October 19, 2011, 10:13:28 am

Title: Overworld Resource
Post by: Josh @ Dreamland on October 19, 2011, 10:13:28 am
Formal proposal time, now that EGM is finished.

Anyone who has tried to make large, complicated rooms in Game Maker has been either bitterly disappointed or ingeniously crafty with regard to GM's rather limited room editor.

The quintessential example of a game that's fucking hard to make in GM is a Metroid platformer. There are two ways to go about the layout of a Metroid game in GM: There is the traditional method of creating a room for each little passage and cranny and using a complicated network of global variables to determine where you are coming from and where you are going, or there's the perhaps more advanced method of creating a large room of room-editor-lagging proportions and then using instances to denote regions to activate or deactivate as needed.

I have, in my longish and complicatedish game making history, made both a 2D and 3D Metroid Platformer, using a version (albeit a crude one) of the above strategies. It's quite possible that I've missed a strategy more form-fitting of Game Maker's... capabilities, but even in retrospect, I am not seeing a better way of pulling it off.

Enter EGM. Enter Overworld Resource.

Now that the EGM format is complete, we are capable of extending the existing room resource and adding a new resource on top of it.

Extending the room resource, we would allow for users to define their own "regions," as MrGriggs called them when he suggested them. These regions would be simple geometric shapes (possibly just box and circle) which, using a new set of room_region_* functions, the user would be able to test for being inside of. We then could have an instance_(de)activate_region function. Other modifications could be made to associate certain resource groups with regions, but this is part of another proposal I should probably post next.

Now, for the new resource, Overworld. Essentially, the overworld resource would allow users to place rooms into a larger room editor, the overworld editor. Ism would pre-render low-resolution previews of the room (she could fetch larger previews upon zoom) and allow users to place them in correct proportion on the Overworld map. A set of functions would be provided to get the full rectangle coordinates of a given room in the map, and contiguous rooms could be mapped together to allow quick searching for neighbors.

With that in mind, rooms could be easily reused without a complicated network of user-defined globals, such as room_to_left, room_to_right, room_above, room_below, or, worst of all, x_coming_from, y_coming_from.

Using the Overworld function set, a user could convert x-y room coordinates to x-y overworld coordinates by adding overworld_get_room_x(room_in_overworld) and overworld_get_room_y(room_in_overworld). The user could then translate those coordinates in the appropriate direction so as to leave the current room (essentially walking the character over), then make two calls to overworld_ functions to determine which room is actually going to be entered, and convert the overworld x-y pair back to room x-y pair after the room has been reassigned.

This topic is a good place for argument as to the exact functions to be made available, and this wiki page is a good place to put the results: http://enigma-dev.org/docs/Wiki/Overworld

Cheers.
Title: Re: Overworld Resource
Post by: Rusky on October 19, 2011, 11:26:21 am
Your description of the overworld resource suggests a rather simple method that would work in GM- separate rooms with a simple global array of their overworld coordinates. This could be somewhat painful, but a new editor like you describe would make it great.

However, game worlds don't always work that way. RPG-style overworlds where the player walks around in a hierarchy of rooms come to mind, as well as slightly more complicated Metroid-style ones with rooms oriented outside of a single, 2D map, such as with doors to other layers and/or rooms extending "into" the world.

A vague suggestion that would accommodate all three of these styles: rather than translating between overworld and room coordinates directly, build the overworld resource out of "connectors" between rooms. These connectors would be associated with doors, room edges, teleporters, etc. on both ends, allowing for much more flexible layout of the game world.
Title: Re: Overworld Resource
Post by: Josh @ Dreamland on October 19, 2011, 08:37:08 pm
I was hoping someone else would suggest that. While that was my original idea, I thought it kind of overcontorted the purpose of most RPGs, but I had mostly older ones in mind. (RPGs, and other games with such needs.) For example, I considered LoZ, too. Most of the time, converting coordinates in one room to those in another is all it takes. But I guess even in Zelda, there were stairs that led odd places.

But yes, teleporters would be really nice; the issue is, how do we sync that up with the room system, and how do we put it to functions? At the moment, I'm really tired. My brain hardly works; it's in write-only mode at the moment. But I'm having trouble thinking of a few concise functions to serve those purposes.

I guess, when I think about it, doors like in Kirby's Adventure would be better pulled off with that system than by overlapping rooms in the editor.

Okay, how about this:
In addition to regions, rooms can define entry points and exit points by a given name. The overworld resource then uses those points, allowing users to link them between rooms by drawing arrows between them. We could then offer functions to go to follow the route pointed to by one such node. Or, in the case that there are multiple, offer an overload of that function that uses a different index, for doors and teleporters that go random places.
Title: Re: Overworld Resource
Post by: Rusky on October 19, 2011, 09:13:52 pm
I like the idea of named entry/exit points. In fact, that would be a nice addition to the instance id system in general- rather than ever exposing instance ids directly, instances could be named and accessed through constants. This could probably be reused to name regions and entry/exit points.

You proposal would make for a nice API- just call overworld_follow(some_endpoint) in e.g. the collision event with a door, and the game would switch rooms and then trigger an event for "followed overworld connector" that gets passed (similar to other in collision events) the exit point in the new room. Other useful functions could be overworld_get_endpoint() and overworld_get_room(). Handling multiple endpoints should probably involve the door collision event picking one rather than any code in the overworld system.

One question is what endpoints should be attached to- instances? regions? points? just names? I'm thinking probably names would be the most flexible, but that could make the overworld editor somewhat annoying as the arrows wouldn't automatically point from some meaningful origin to a meaningful exit point.

Another problem associated with using names would be resolving the new coordinates. If all you have is the name of an endpoint, you would have to do a lot of work yourself, negating the advantages of an overworld editor.

A possible solution to these problems would be to associate some arbitrary piece of data with each endpoint, including instances, points, regions, etc. This might be tricky to do in the overworld editor, but it could lead to a lot of flexible configurations for different styles of games. If there is a good way to do this, arrows would have meaningful endpoints and the room-entry events would be able to grab the data in whatever way the game is designed to use.