Multiple Games on the Same MUSH?

[Deleted]

I know zilch about coding but I'm curious about why every game that comes out is on its own server.

Would it be possible to have a single MUSH address host multiple games? You appear in the start room when you make a character and then select which game you play from the list available and go from there.

I imagine it'd be difficult to code different 'approvals' so you don't get people from the wrong game on the wrong grid. And different staff buckets for different games. And etcetera.

Plus they would all need to be the same game system if they're going to share chargen elements.

But what if you run multiple single-sphere chronicles on the same MUSH? I imagine that would be somewhat easier to handle, code-wise. Since you wouldn't need to separate things any more than they are on any multi-sphere game. You'd just need separate grids and that's just a matter of building rather than code.

The reason this popped into my head was because I was looking at MU*s out there and population is an important indicator to me on if I am willing to try a game. If there's no community for it, well. I guess the game itself isn't worth my time.

However, if these single-sphere games were merged into a single MUSH hub (possibly even with a shared OOC experience between them) it might make them more attractive to players while also allowing games to survive with the smallest of playerbases.

Does anyone have any thoughts on this? It might be as bad as my pay-to-play idea, for all I know.

Edit: Fixed some grammatical issues and the title. Whoopsie.

[Coin]

@Admiral said:

I know zilch about coding but I'm curious about why every game that comes out is on its own server.

They aren't.

Would it be possible to have a single MUSH address host multiple games? You appear in the start room when you make a character and then select which game you play from the list available and go from there.

These exist.

I imagine it'd be difficult to code different 'approvals' so you don't get people from the wrong game on the wrong grid. And different staff buckets for different games. And etcetera.

Harder than it seems, but far from impossible.

Plus they would all need to be the same game system if they're going to share chargen elements.

Not necessarily.

But what if you run multiple single-sphere chronicles on the same MUSH? I imagine that would be somewhat easier to handle, code-wise. Since you wouldn't need to separate things any more than they are on any multi-sphere game. You'd just need separate grids and that's just a matter of building rather than code.

The reason this popped into my head was because I was looking at MU*s out there and population is an important indicator to me on if I am willing to try a game. If there's no community for it, well. I guess the game itself isn't worth my time.

However, if these single-sphere games were merged into a single MUSH hub (possibly even with a shared OOC experience between them) it might make them more attractive to players while also allowing games to survive with the smallest of playerbases.

In general people who want "populated MUs" want them for the scattershot "I can always find RP" value. What you're suggesting wouldn't really work since even if the other spheres are booming, if yours isn't, you're shit out of luck (unlike multisphere games, where you can cross over).

[Arkandel]

@Admiral said:

I know zilch about coding but I'm curious about why every game that comes out is on its own server.

It's basically like this:

A server is a machine. It doesn't run 'games', it runs all sorts of things, some of which are games like a MU. It's very rare these days for a server other than some piece of hardware in someone's literal basement to be used for just one game, since it's extremely wasteful. You know the port any MU ever uses (6000, 8100, whatever)? That's so the server knows which of these more-than-one programs it's running you're talking to.

What MU* runners usually rent is a share on a server. You're given some space on their drives, access to their database, etc.

An address is just that - it's an arrow pointing at the server above. More than one of those arrows can point to the same server. It's the port that differentiates which is which.

So for example a server like mechanipus.com can (and does) run a bunch of games. Eldritch conducts its business at port 6666.

Would it be possible to have a single MUSH address host multiple games? You appear in the start room when you make a character and then select which game you play from the list available and go from there.

I think what you're talking about isn't different games. It's one game with different grids, staffs with +job buckets of their own, and a central nexus with exits leading to those different grids. But you'd also need separate channels, +events, separate controls so staff from one game can't spy on players from the others, etc.

It's not necessarily a bad idea, you could try to flesh it out further, but the administrative logistics is what could do it in even before you can solve the code issues of segregating every single thing between the sub-grids. The overhead might make it save less than you may think it should compared to the traditional model, but once you explain how you'd deal with the above maybe there could be merit in it.

[Roz]

At the very least, I know of Pern games that have more than one grid that technically exist within the same world but basically function as two separate entities.

[Arkandel]

@Roz said:

At the very least, I know of Pern games that have more than one grid that technically exist within the same world but basically function as two separate entities.

Yes, but staff is the same for all, policies are identical, etc right?

[Ashen-Shugar]

@Arkandel said:

@Roz said:

At the very least, I know of Pern games that have more than one grid that technically exist within the same world but basically function as two separate entities.

Yes, but staff is the same for all, policies are identical, etc right?

Depends on the game. There's a few muds/mushes out there that have a multi-tier environment. Each sub-game has their own layer of staff, global code, zone, parent trees, etc etc. I'm not familiar with all the details, but it would be possible to cross-link world-global code, then using methods in whatever flavor of hardcode (mux, tm3, rhost, penn, diku, whatever) use the tools available to segregate each individual sphere into its own domain.

Kinda like having the mush engine as a VCenter and each individual sub-world as a VM on it. Nifty idea, can be done, but would take additional work to make it work cleanly.

[Arkandel]

@Ashen-Shugar Then that sounds like what @Admiral is looking for.

[Bobotron]

@Admiral
It can be done, and I've seen it before, though it was games following the same theme. The code that goes into it is moderately difficult, but it can be done; zones become a very important thing for having game-specific information/code/etc. from a player standpoint. A bit more to do, to make it work on staff end (using absolute references and probably having no wizards, since wizards can just about change anything, regardless of who owns it or locks), but could be done.

[Kosh]

Otherspace did this many year ago.. I want to say around 2001 to 2003 when Conflicts of Earth merged with them and both games were on the same server (played both games at the time, and was staff on CoE).

Code wise, it wasn't a big deal.. Both used HSpace, they each used their own Room Parents.. Bboard system was just a matter of setting up special boards for the new game and setting the permissions accordingly. Both ended up using the same CharGen system.

It really wasn't a huge thing regarding setup. It worked out well in the end. Not sure why it ended.. I think the CoE head admin had a falling out with Brody (think there was some sort of conflict in the background, I have my theories by nothing confirmed).

It's doable.

The reason they did it was CoE had a smaller playerbase, and the idea was that there was hope that both player bases would create alts in the other game. Staff was split between CoE and OS (although when CoE left, several staff members were absorbed into the OS team).

[Alzie]

Restricting commands to a subset of the grid is as easy as maintaining a good set of Zone Master Objects. Zone your games and set your commands so they only work in those particular zones. Done. As always, this works great on Mux and Penn, but Rhost has to redefine the wheel and Zones don't work at all like they do on the other two.

[Groth]

@Admiral said:

Does anyone have any thoughts on this? It might be as bad as my pay-to-play idea, for all I know.

We talked about this on RFK a few times as we and Shavalyoth believed that the best way to run a game is to focus on a single sphere and do it well rather then try to do multiple spheres at the same time. Running several different games on the same server would be one way to let people who prefer other spheres to also be part of the fun.

The main reason we never did it was because we wouldn't want to share server with a game we couldn't feel sure would be high quality, we didn't have the manpower to run a second game by ourselves and it's really hard to find people that can run a good game. However if you want to run a vampire game and a werewolf game at the same time, I certainly don't think running them as two separate grids of the same game is a bad idea.

@Arkandel

But you'd also need separate channels, +events, separate controls so staff from one game can't spy on players from the others, etc.

Why would you need that? It seems to me that sharing channels, events, staff controls etc is one of the only reasons to run the spheres off the same game. If you want to split all of that you might as well run them entirely separate.

[Ide]

Someone on another mud forum proposed an interesting idea once to make a game that was three different games in one.

As I recall it was a prehistoric setting but you could adapt it to other ones. The three games were something like:

• A PK sabre-toothed tiger game. As a tiger you couldn't use says and so on with other players, you'd have territory that you'd fight other tigers for, etc.

• A PvE wolf game. You'd have a wolf pack with other players, battle the tigers, and then hunt around and stuff. You wouldn't have says per se but you'd have other forms of communication with your wolf pack.

• A RP cave people game. There'd be some game mechanics to fend off the tigers and wolves but it'd primarily be a mush RP style game.

As a character in one of the sub-games it would be like you didn't know there were other sub-games coinciding with yours, but as a player you still would get to interact ICly/OOCly with the other games. So it's a way to bridge different player wants/needs and make a bigger game than would be possible if you opened these three sub-games as separate niche games, which I think is the strength of an idea like this.

[Bobotron]

@Groth
Some games, like MuxNexus are LITERALLY 'this MUSH hosts many games, each with their own grids, separate staff, etc.'

[Ashen-Shugar]

@Alzie said:

Restricting commands to a subset of the grid is as easy as maintaining a good set of Zone Master Objects. Zone your games and set your commands so they only work in those particular zones. Done. As always, this works great on Mux and Penn, but Rhost has to redefine the wheel and Zones don't work at all like they do on the other two.

Welll.... not... entirely... correct. There's some settings you can set that will allow zones in Rhost to have zoneparents, inheritance, zonemasters, and all that jazz similar to how they work in Penn and/or MUX and/or TM3. How you assign zones though is different, that I'll grant you. The biggest difference is that Rhost allows things to belong to multiple zones at the same time, keeps all the zone information hashed in memory for faster lookups, and allows command overriding and/or restriction based on zones. So you could, for example, have say and pose work differently based entirely on what zone you're currently standing in. This allows a much more flexible form for exactly the case being described here. Sometimes, reinventing the wheel pays dividends, sometimes it doesn't.

[Lithium]

It wouldn't be that difficult to have multiple games on the same port, you could even use different code for each you'd just have to differentiate the commands so as to make sense.

I remember there was a GI Joe and Super Heroes mixed game, and Tarterus had like 3 games on it I think...

I just wish I could actively use more ports though, then I would build all four of the ideas running around in my head, and open them all at the same time.