04 Nov, 2009, Impacatus wrote in the 1st comment:
Votes: 0
I'm not sure I have the terminology right, but hopefully you can understand what I mean.

Let's say there's a mud you like but in your view it's missing one feature, and you're not the only one. You're too attached to the community to start a competing mud.

For example, let's say you want to add PvP. You create a special server that everyone who wants PvP can log into. Most of the time, this just relays commands to the client from the official server and back. However, when you want to fight a PvP battle with someone else on the special server, it uses the stats to of the two characters to run a battle. Once it's resolved, it makes the loser hand over their inventory and commit suicide.

Like the other thing I asked about, more of a novelty than anything else, but I'm curious if this has ever been done.
04 Nov, 2009, Zeno wrote in the 2nd comment:
Votes: 0
But wouldn't that require the server (MUD) to code in something to handle all this? If the MUD is missing something you want and is not willing to code it in, I doubt they would be willing to code something else in to "hand off" this feature.
04 Nov, 2009, Impacatus wrote in the 3rd comment:
Votes: 0
Not necessarily. Admittedly, only people on the alternate server would be able to see what's going on, but if it has control of all the accounts involved, then it could alter them by whatever means necessary.

Like the PVP example. All the alt server really needs is:
-the stats of the two players
-the ability to transfer spoils from the loser to the winner

To the official server, the whole battle might look something like this:
playerA: get stats
playerB: get stats
playerB: give all to playerA

The whole battle is run in the alternate server. Once it's determined that playerA is the winner, the alternate server simply makes playerB hand over his/her possessions.

I'll admit, I don't really see a big need for this, I just thought it might be interesting to think about.
04 Nov, 2009, Confuto wrote in the 4th comment:
Votes: 0
I know someone created an intermediary client for one of the Iron Realms games that essentially relayed information from the server to the actual client. The advantage of doing this was that it could be used to create compiled modules written in C that would have otherwise been written in a particular client's scripting language. I think a mapping module was created (back when IRE games didn't have mapping, I assume) as well as a combat module and even an IRC module.

While this system was used primarily by individual players, the way it operates is somewhat similar to what you describe. Essentially it would connect to a particular server and then start a server of its own. The user would connect to this local server, which would relay information back and forth, processing it as necessary. I doubt it could handle multiple connections to the one intermediary server, but modifying it to do so wouldn't be impossible.

Unfortunately the interesting part of the software is very tightly integrated with the game-specific stuff, but it's open source, and you can find it here.
04 Nov, 2009, Impacatus wrote in the 5th comment:
Votes: 0
Ah, so it has been done to a certain extent. Awesome, thanks.
04 Nov, 2009, Zeno wrote in the 6th comment:
Votes: 0
Impacatus said:
Not necessarily. Admittedly, only people on the alternate server would be able to see what's going on, but if it has control of all the accounts involved, then it could alter them by whatever means necessary.

Like the PVP example. All the alt server really needs is:
-the stats of the two players
-the ability to transfer spoils from the loser to the winner

To the official server, the whole battle might look something like this:
playerA: get stats
playerB: get stats
playerB: give all to playerA

The whole battle is run in the alternate server. Once it's determined that playerA is the winner, the alternate server simply makes playerB hand over his/her possessions.

I'll admit, I don't really see a big need for this, I just thought it might be interesting to think about.


But what about skills? Item data? Etc. You would need the formulas on skills and the sort in combat, and only the original MUD would have that. Unless I'm still not understanding what you mean.
04 Nov, 2009, David Haley wrote in the 7th comment:
Votes: 0
Proxy servers have been done several times for many reasons. But you're not talking about just a proxy server that sits in between and does a few things; you're talking about an entire proxy game.

You've already identified two very simple problems illustrating why this wouldn't really work without cooperation from the main server: how exactly would this proxy game get the stats on the players, and the ability to transfer spoils? You say that's "all it needs", but, well, that's a pretty big "all".
04 Nov, 2009, Confuto wrote in the 8th comment:
Votes: 0
David Haley said:
Proxy servers have been done several times for many reasons. But you're not talking about just a proxy server that sits in between and does a few things; you're talking about an entire proxy game.

You've already identified two very simple problems illustrating why this wouldn't really work without cooperation from the main server: how exactly would this proxy game get the stats on the players, and the ability to transfer spoils? You say that's "all it needs", but, well, that's a pretty big "all".


One could presumably grab a character's stats by using a score or stat command, parsing the results and not displaying it to the player. Similarly, transferring a character's inventory would be a matter of parsing the inventory command output and then inputting give commands for each item, displaying only a "You lose the battle and your inventory is transferred." message or similar to the losing player. While I don't really think this would make for a good (or even decent) extra combat system, it's certainly do-able. The issue is, of course, that the proxy game can only interact with the server through the player characters, which isn't too useful.
04 Nov, 2009, David Haley wrote in the 9th comment:
Votes: 0
The server is supposed to act as a proxy for not just one player, but for all players. It would have to be somehow logged in as each at the same time to do the things you described – that in and of itself can be a problem on several MUDs (e.g. ones that forbid multiplaying).
05 Nov, 2009, Lobotomy wrote in the 10th comment:
Votes: 0
I would imagine this proxy server having access to the user names and passwords of multiple players as presenting something of a security issue as well. Who's to say that the person(s) running the proxy are trustworthy and/or competent enough to safely handle such information?

Edit: Fixed a typo.
05 Nov, 2009, Confuto wrote in the 11th comment:
Votes: 0
As I said, not a particularly great idea.

That said, are there any potential uses for creating "add-on" servers for games with cooperation between the add-on and the main servers? I could imagine one add-on server for roleplayers, another for PKers and so on, but don't really see a point to doing that.
05 Nov, 2009, David Haley wrote in the 12th comment:
Votes: 0
I don't really see a huge demand for this, and demand I see could really be solved by having some kind of server-side plugin mechanism. I completely see the point to the "same game" with different features turned on or off, but I don't really see the point for having all of these game instances coexist, with people interacting with each other, but following entirely different game rules. (I'm not sure what that would even mean, really. What happens if somebody from the hack-and-slash game instance attacks something from the roleplaying game instance??)

What exactly is the use case here that brought up the question?
05 Nov, 2009, Impacatus wrote in the 13th comment:
Votes: 0
Quote
One could presumably grab a character's stats by using a score or stat command, parsing the results and not displaying it to the player. Similarly, transferring a character's inventory would be a matter of parsing the inventory command output and then inputting give commands for each item, displaying only a "You lose the battle and your inventory is transferred." message or similar to the losing player. While I don't really think this would make for a good (or even decent) extra combat system, it's certainly do-able. The issue is, of course, that the proxy game can only interact with the server through the player characters, which isn't too useful.

Yeah, that's pretty much it. I don't see why the combat system would be intrinsically worse than the one provided by the MUD itself. Maybe you're thinking of something more advanced. RPG combat is pretty much rolling dice and adding or subtracting HP, MP, and so on. It may not have access to the exact formulas used by the MUD's pve, but with some effort you could get it close enough.

The multiplaying issue would only come be a problem if the MUD indeed prevents multiplaying. The trustworthiness of the people running the proxy could be established over time through word of mouth. Yes, someone might try to scam others that way,

There really isn't much call for this in the MUD community, probably because there are so many and it's easy enough to hack the codebases to do what you want. In the graphical MMO market it might make more sense, because there are a few games with a lot of players each. A lot of players in each game have contradictory values, and it's much harder to update the game to fix it's shortcomings.

This isn't a serious suggestion. I like exploring new ideas just for the heck of it. It's important to keep this in mind, because what I'm about to say next is even crazier.

What if you used this technique to make a fully modular and community customizable MUD/MMORPG server?

You'd start with the "official server". Maybe this just handles logins and that's it.

Then you chose from a list of third-party race/class/skill system proxies and connect it to the official server.

Then you connect to that proxy with your choice of inventory/item system proxies.

Then you connect to that one with a world proxy filled with objects that can be interacted with through your skill and item systems.

…and so on. Each server is specially designed to work with the next one in the list. For example, if you have a choice between "Bob's skillset" and "Joe's Classes", at the next level you might find "Gold and weapons of Croesus" and "Marty's Manufacturing" designed to work with "Bob's skillset", and a different set of systems for "Joe's Classes".

Yes, yes, I know. It's way too impractical and completely unnecessary. It's would get unmanageably complicated as you worked your way down the list, and the resources involved would be better put towards developing separate games. Still, it's fun to think about.
05 Nov, 2009, elanthis wrote in the 14th comment:
Votes: 0
Such proxies are not fun to think about. They're broken by design from a game play perspective, in that you as a player would be forced to pick a single proxy to connect to, and hence a single feature set to extend the game with. It's not just impractical, it's worthless.

If you want to think about ways for community members to extend game worlds in isolated ways, you'd want to think more along the lines of what most MUSHes or things like Second Life already do, in that they allow user-contributed logic modules that use isolated storage systems for the development of user logic extensions that can interact independently or in concert with other modules in well-defined manners.
05 Nov, 2009, David Haley wrote in the 15th comment:
Votes: 0
Impactus said:
Yes, yes, I know. It's way too impractical and completely unnecessary. It's would get unmanageably complicated as you worked your way down the list, and the resources involved would be better put towards developing separate games. Still, it's fun to think about.

Are we trying to think about something practical that could lead to releases and use, or just some abstract thought experiment about something that might be nifty? I guess I'm not really sure what the point of this exercise is, since it seems to me that we're faced with technical near-impossibility (or incredible lack of practicality at best), lack of necessity, and no real use case to motivate this.

If the idea is to make plug-and-play gameplay, why not do that at the server level first? It's hard enough to freely mix and match rulesets when you're in total control of the game, let alone when you have to work through some funky proxy system and talk to a server that isn't cooperating. If you do it at the server level, you can go with well-defined user extension modules, like what Elanthis referred to.
06 Nov, 2009, Impacatus wrote in the 16th comment:
Votes: 0
David Haley said:
Are we trying to think about something practical that could lead to releases and use, or just some abstract thought experiment about something that might be nifty? I guess I'm not really sure what the point of this exercise is, since it seems to me that we're faced with technical near-impossibility (or incredible lack of practicality at best), lack of necessity, and no real use case to motivate this.

It doesn't really have a point, just a bizarre thought I stumbled across, possibly while sleep deprived. You can do whatever you want. :wink:

Quote
If the idea is to make plug-and-play gameplay, why not do that at the server level first? It's hard enough to freely mix and match rulesets when you're in total control of the game, let alone when you have to work through some funky proxy system and talk to a server that isn't cooperating. If you do it at the server level, you can go with well-defined user extension modules, like what Elanthis referred to.
The advantage of using proxies is that the different rulesets could be designed completely independently from each other, without any cooperation or centralization. Anything on the server itself would require cooperation with the MUD admin, while this would not.

Quote
Such proxies are not fun to think about. They're broken by design from a game play perspective, in that you as a player would be forced to pick a single proxy to connect to, and hence a single feature set to extend the game with. It's not just impractical, it's worthless.
Maybe you should set up a competing hotline to that 1-800 TBS funny. People could call you and ask if what they're doing is fun. :biggrin:

Multiple proxies could be linked up in a chain, if necessary.

Not saying the situations are equivalent, but looking back, agriculture was a really, really bad idea. It drastically increased the labor requirements of a society, it forced them to settle leaving them vulnerable to disease and invasion, it dramatically reduced the quality of nutrition, and it had the potential to cause a famine whenever there was a crop failure. But look where we are today.

What if we think smaller. Proxies could easily be used to add some new emotes. They could provide a moderated environment with different rules than the main server, at least when it comes to chat. They could be used to enforce things like the "permadeath" pacts in D&D Online. It just needs to keep the passwords from the players so they can't log in without the proxy.

By the way, I forgot to thank you, David Haley, for the term "proxy". Exactly the word I was looking for. :smirk:
06 Nov, 2009, Cratylus wrote in the 17th comment:
Votes: 0
Impacatus said:
For example, let's say you want to add PvP. You create a special server that everyone who wants PvP can log into. Most of the time, this just relays commands to the client from the official server and back. However, when you want to fight a PvP battle with someone else on the special server, it uses the stats to of the two characters to run a battle. Once it's resolved, it makes the loser hand over their inventory and commit suicide.


06 Nov, 2009, David Haley wrote in the 18th comment:
Votes: 0
Impactus said:
Not saying the situations are equivalent, but looking back, agriculture was a really, really bad idea. It drastically increased the labor requirements of a society, it forced them to settle leaving them vulnerable to disease and invasion, it dramatically reduced the quality of nutrition, and it had the potential to cause a famine whenever there was a crop failure. But look where we are today.

Err.. what? :surprised:
06 Nov, 2009, Runter wrote in the 19th comment:
Votes: 0
David Haley said:
Impactus said:
Not saying the situations are equivalent, but looking back, agriculture was a really, really bad idea. It drastically increased the labor requirements of a society, it forced them to settle leaving them vulnerable to disease and invasion, it dramatically reduced the quality of nutrition, and it had the potential to cause a famine whenever there was a crop failure. But look where we are today.

Err.. what? :surprised:


Yes. So, really, really bad ideas are actually really good ideas. I'll keep that in mind when designing my protocols in the future.
06 Nov, 2009, Idealiad wrote in the 20th comment:
Votes: 0
If you start overusing the terms 'good idea' or 'bad idea' I think you'll run into many problems. In the case of agriculture I think it's better to call it 'an idea with serious consequences' :).

On point, this proxy idea sort of reminds me of peer to peer MMO networks. What if you extended that idea so that players could indeed run locally modded versions of the main game? I think that could get quite interesting.
0.0/27