Hub Help

[Cronyne]

I plan to use some hubs in the future, but I have little idea on how to do that. The ZDoom wiki cannot help me in this case, and I've searched throuhg a couple forums including this one (unless the searcher is malfunctioning.).

What I really need is a few examples of working hubs for me to analyze, or maybe a thorough explanation, please.

[Zippy]

The ZDoom wiki cannot help me in this case

I beg to differ.

[wiki]MAPINFO[/wiki]. Specifically, [wiki=MAPINFO/Cluster_definition]Cluster definitions[/wiki] which are used to define collections of maps which you can set to be a hub. Even more specifically, the part where it says

* hub

Indicates that this cluster is a hub. When leaving a hub, the game will remember the contents of the level when the player left it and restore the level to that state when the player returns to it. Moving to a different cluster will cause the game to forget the state of the levels in this hub in order to save memory. Each level a player visits in a hub uses memory (about 20k for a typical level), so it's probably a good idea not to have too many levels in a single hub. Just how many is "too many" is arbitrary. Unless you use very large levels, you could probably use 50 levels in a hub, and only about 1 meg would be required to keep track of the state of each level.

All you need to do is define your maps in MAPINFO together in a cluster and mark it as a hub (define the cluster and then in each map that's supposed to be part of that cluster should include the "cluster = <clusternumber>" property). Then in the levels set up your appropriate [wiki=Exit_Normal]Exit specials[/wiki] to point to the corresponding start spots in each others levels.

[Cronyne]

The wiki didn't help me in the case of no hub-specific examples.

So, if I understand correct, putting the cluster number under a 'map' definition, and then writing hub into that cluster definition later will link them?

If this is the solution, thank you very much!

[Zippy]

Yes.

A "cluster" is just a definition of some grouping of maps that is NOT an episode (the episode definition is something else altogether). The main thing behind a cluster is that you get the enter an exit texts when entering/exiting a cluster of maps. So, MAP01-MAP06 of Doom 2 are a cluster as leaving the cluster (exit of MAP06) to go to MAP07 (start of the next cluster) produces the exit text you see for Dead Simple. The hub keyword in the cluster definition tells the engine that when you leave a map in the cluster for another map in the same cluster, it should save the state of the map you left and load it if you ever go back to that map. Otherwise the default behavior is to forget everything and if you go back to a map it starts from scratch. With that, all that's left is to point out which maps are in the cluster, which is done with the cluster keyword in the map's definition. When you define a cluster you have to give it a number, and when you define the map you can give it that cluster number to tie them together.

[Cronyne]

Sweet, thank you very much!

[ItsNatureToDie]

With all that said, how do you prevent the player from spawning from the wrong spot when you go from one map to another? Example being one map has two player one starts, one to begin level and the other to come back from other map. While the other map only has one player one start. Bottom line is how do you set up a way to go from hub to hub without problems?

[Shadelight]

I think the way multiple player starts work is that you have to use the first argument in a player start, I could be mistaken though, it's been a while since I first tried a hub.

[ReX]

With all that said, how do you prevent the player from spawning from the wrong spot when you go from one map to another? Example being one map has two player one starts, one to begin level and the other to come back from other map. While the other map only has one player one start. Bottom line is how do you set up a way to go from hub to hub without problems?

As BlazingPhoenix mentioned, the player starts can be assigned an argument number. The default value is 0, and always applies to the player start upon map start-up. The player-start with an argument value of 1 can be used for the return from a second map, value 2 for return from a third map, and so on. You can even have multiple returns from another map - i.e., player returns to Map01 from two different points on Map02.

There have been many hub-based wads. Some that I have developed are:

Paranoid (8 maps in a hub) - this one has a map that can be entered from 4 different points from 3 other maps.
Eternal DooM IV: Return From Oblivion (3 maps in a hub) - this one is particularly "complex" as each map has two exit points, each one going to a different map in the hub. This (together with appropriate scripting for weapons & enemy spawning) allows the hub to be played in several different ways for a different gameplay experience each time.
Temple of the Ancients (5 maps in a hub)
Paranoia (5 maps in a hub)
The Darkest Hour (7 maps in a hub)
Dawn: A Prelude (5 maps in a hub)

[ItsNatureToDie]

My thanks gose out to you Rex and BlazingPhoenix. Till now i had a bitch of a time setting up player starts all because of there being no wiki page on it. as for the wads, I am checking these suckers out.

[ReX]

What I really need is a few examples of working hubs for me to analyze, or maybe a thorough explanation, please.

I probably should have mentioned this in my previous post, but I'll do it here. A "hub" structure is a loose definition of the original "hub & spoke" structure. A hub & spoke design is one where there is a central map (the hub), and peripheral maps connected to the hub via spokes. [Very similar to a cart wheel, with the central hub being the point through which the entire structure connects.] A good example is the first Hexen mission. Incidentally, some maps in The Darkest Hour also follow this structure. Subsequently, any collection of maps that allow players to return to maps already traversed (or allowed back-and-forth travel between maps) became known as hub-based wads.

Assuming, for a moment, that you have a true hub-spoke wad in which the player starts in the hub map and can travel to 3 other maps, you'd do the following:

• 1. In the "hub" map, your Player 1 start would have a default argument value of 0. [Let's say the map is Map01.]
  2. In Map01, you'd have exits to each of your other maps. For simplicity's sake, assume the player returns to Map01 at the same point that s/he leaves it. At each exit you would have a player start. For the exit/return point for Map02, you can assign an argument value of 1 to the player start (although you can just as easily assign an argument value of 2 or 3 if you wish). For the exit/return point for Maps03 and 04, you can assign an argument value of 2 and 3 to the respective player starts.
  3. In Map01, your exit command would use Teleport_NewMap (map, position). So, to exit to Map02, you'd have Teleport_NewMap (2, position). For the sake of simplicity, assume the position (which is the player start argument value for the destination map) is 0. So your exit would be Teleport_NewMap (2, 0).
  4. In Maps02 to 04, assign an argument value of 0 to the respective player starts. (You can assign a different value, depending on the argument you use in the exit command from Map01. See 3, above.)
  5. In Maps02 to 04, create your exit points to return to Map01.
  6. For Map02, your exit command would be Teleport_NewMap (1, 1); for Map03, it would be Teleport_NewMap (1, 2); and for Map04, it would be Teleport_NewMap (1, 3). The position values here correspond to the player start arguments you assigned in 2, above.

If you wanted to create direct connections between the peripheral maps (i.e., Maps02 to 04) that would not require going through the hub (Map01), you'd create similar exit/entry points, taking care to use different player start arguments (unless the entry points happen to coincide with those from Map01, in which case you wouldn't need new arguments).