By default, the entry in the hub is just the name of the game (world.name). Players can click on it to log in.
Since some games may have different phases (like "waiting for players", "game in progress", etc.), you can assign a description of the phase you are in to world.status. This will be displayed in the hub entry so that players can tell what they are in for before clicking on the link.
Just that functionality alone will be good enough for most games, but some distributed games (ie player hosted) may need their own private hub area. This can be done by registering your own hub entry and then assigning the unique "id" that it gives you to world.hub. Then your game can pop up a browser page that shows just your game and all of the currently active instances of it that are running. You do this with a URL to the hub cgi script including the "id" of your hub entry as a parameter.
In addition to world.status and world.hub, there is also a new world.version var. If you are distributing your game to players, you can use this to automatically notify players when a new version is available. You do that by recompiling with an incremented world.version and updating the official version number in your hub entry. When a player connects up using an outdated version of your game, they will be notified of the new release.
Players who log into a registered hub game will now be automatically notified if there are other existing "live" instances of the game. This is primarily of use for distributed games (hosted by players). For example, a player boots up DragonSnot and is notified that there are other people already hosting games. The player can then click on the hub link that is provided and see the full list of DragonSnot games in progress and possibly join one instead of waiting around for others to join.
One nice thing about that scenario, is that by booting up the local game first, the player is sure to have the game's resources pre-loaded into byond.rsc, which means other people's hosted games (some of them on mere modems) won't have to server up a lot of resource files.
This distributed model of game deployment is very promising, because it allows your game (and BYOND as a whole) to grow very quickly without a big investment in massive central servers (which would probably still get bogged down). Instead, the central server is reserved for testing new releases, single-instance worlds (such as MUDs), and the hub. That's much more light-weight and affordable than trying to host every glitzy little game in one place. Our goal with the hub, the pager, and so forth is to bind it all together so that from the player's point of view, the entire Internet is one big BYOND server. Muuuaaaaahahaha!
Don't worry about memorizing all of the hub details for now. We'll put some examples of usage up once the online version is completely functional.