24 Feb, 2013, salindor wrote in the 1st comment:
Votes: 0
So I am curious, does anyone know of a mud being developed using cloud technology?
24 Feb, 2013, Arithorn wrote in the 2nd comment:
Votes: 0
I'm using Linode to develop mine on but I still have a long way to go. Much cheaper than running a system at my house 24/7.

To add to that, I also use Dropbox (free) to synchronise the code to my systems and MozyHome (free) for daily backups.
25 Feb, 2013, salindor wrote in the 3rd comment:
Votes: 0
I tried dropbox for that purpose, but it was too slow so I ended up switching to subversion.

I should have been more specific using api's that let the mud take advantage of being in the cloud vs just running in the cloud. Though I am curious how its been working for you? have you noticed any noticable lag? Why do you think its cheaper than running out of your house?
25 Feb, 2013, Idealiad wrote in the 4th comment:
Votes: 0
It really depends on your electricity costs and how big of a VPS you have. I'd say in general, for higher-end servers, a home server is less expensive in pure dollars. Of course there are other considerations.
25 Feb, 2013, Arithorn wrote in the 5th comment:
Votes: 0
I don't have a low-power system, only a gaming desktop at around 160W usage (when not gaming), it works out to be about $35/month in just electricity costs. I'm in Australia and our power prices here are approaching the ridiculous. My Linode costs me between $18-$20 per month depending on where the currency is at. And this way I don't need to worry about UPS/DSL dropouts etc.

Dropbox takes about 5-10 seconds generally which is fast enough for me - and has the added benefit of being available for changes wherever I am. Might take a look at subversion if speed becomes an issue.

Linode has been awesome, no downtime for the past couple years (touch wood!) and great documentation available for securing/configuring the default servers. I haven't noticed any lag either, except for when my mud misbehaves and uses 200% CPU :)

MozyHome has been great, although (again with the wood) I've only had to restore once. I also cron'd a script to email a backup (code & dbase) to my Gmail account just in case.

I haven't investigated any of the Cloud API's available simply because I've had no need for them.
26 Feb, 2013, Runter wrote in the 6th comment:
Votes: 0
I have a git repo inside of my dropbox folder. Then I also have a private github repo that I push to.
26 Feb, 2013, Tyche wrote in the 7th comment:
Votes: 0
salindor said:
So I am curious, does anyone know of a mud being developed using cloud technology?

Pretty much all muds were developed in and run in the cloud.
26 Feb, 2013, Lyanic wrote in the 8th comment:
Votes: 0
Tyche said:
salindor said:
So I am curious, does anyone know of a mud being developed using cloud technology?

Pretty much all muds were developed in and run in the cloud.

Thank you. I almost posted the same reply earlier.
26 Feb, 2013, salindor wrote in the 9th comment:
Votes: 0
Lyanic said:
Tyche said:
salindor said:
So I am curious, does anyone know of a mud being developed using cloud technology?

Pretty much all muds were developed in and run in the cloud.

Thank you. I almost posted the same reply earlier.


Cute, but the cloud refers to the scalabe api's etc that allow for extra servers to be brought up or down based on demand. For example when ESPN has is going to cover a major football game, they will preload several extra servers for their forums so customers never see the extra demand.

Of course it really is overkill for a mud, but was still curious, you never know what you might find out there.
26 Feb, 2013, Kelvin wrote in the 10th comment:
Votes: 0
"The cloud" is a term that means different things depending on who you ask and the context. I think the point is that the initial question wasn't very specific, leading to an answer that was similarly broad.

I may suggest to the original poster that he/she get more specific.
26 Feb, 2013, salindor wrote in the 11th comment:
Votes: 0
Actually cloud technology is pretty specific.

cloud technology
26 Feb, 2013, Kelvin wrote in the 12th comment:
Votes: 0
salindor said:
Actually cloud technology is pretty specific.

cloud technology


Yes, a set of search results with various different things and definitions is a great illustration of your point :)

But really, what is it that you're wanting to know? Is there a specific concern you have? "The cloud" is the latest unfortunate buzz word.
26 Feb, 2013, Runter wrote in the 13th comment:
Votes: 0
Scalable (the expectation that you can spin up many instances without reconfiguration and work together) and location agnostic (might be on the same EC2 instance, might be in different ec2 instances) has become synonymous with cloud computing in the last few years. I doubt most muds were created under those circumstances, or with those considerations in mind. If that's what your question is.
26 Feb, 2013, Lyanic wrote in the 14th comment:
Votes: 0
salindor said:
Cute, but the cloud refers to the scalabe api's etc that allow for extra servers to be brought up or down based on demand.

No. That is an example of cloud technology, not the definition.

Kelvin said:
"The cloud" is a term that means different things depending on who you ask and the context.

Yes. Cloud technology is essentially defined as "* as a service" where * can be just about anything and said service is delivered over a network.

salindor said:
Actually cloud technology is pretty specific.

No. It's one of the most generalized and ambiguous terms in use in technology today.

Kelvin said:
"The cloud" is the latest unfortunate buzz word.

Yes.
26 Feb, 2013, quixadhal wrote in the 15th comment:
Votes: 0
To the cloud!
02 Mar, 2013, Kelvin wrote in the 16th comment:
Votes: 0
I can't wait for this damned buzz word to fall out of fashion :)
02 Mar, 2013, salindor wrote in the 17th comment:
Votes: 0
I wanted to thank everyone for their responses and apologize for being a little short when there was no need to be.

I did mean the scalable service type. I wasn't expecting anyone to have used it, but you never know unless you ask. I was surprised earlier on another posting some of the things the community is working with.

If 'the cloud' follows the same trends as its predecessors prolly about two years when it fails to live up to its promise of turning water into wine and they invent the next best thing that really will turn water into wine! (until they prove it also can't).
02 Mar, 2013, Ssolvarain wrote in the 18th comment:
Votes: 0
Lando Calrissian could help with this, I bet.
03 Mar, 2013, Tyche wrote in the 19th comment:
Votes: 0
salindor said:
I did mean the scalable service type. I wasn't expecting anyone to have used it, but you never know unless you ask.

I used it back in 1990. It was called a sysplex. I wasn't working on muds then. ;-)
03 Mar, 2013, salindor wrote in the 20th comment:
Votes: 0
Tyche said:
salindor said:
I did mean the scalable service type. I wasn't expecting anyone to have used it, but you never know unless you ask.

I used it back in 1990. It was called a sysplex. I wasn't working on muds then. ;-)


Ha, ya. I forgot about just plain parallel computing. Back in college I took a parellel computing class targeting a beawolf cluster. Never really used the knowledge much, and the techniques they taught don't seem to be useful for a mud.

But then when you look at a game like legauge of legends or world of warcraft; you know they are using a multi-layered approach to handle the volumn of players. Even though I have zero aspirations that my game would require such an approach, its fun to think and contemplate "What if I did?" How would I do it? I am still baffled on how to grow a server beyond a single computer. I mean I guess you could easily split the database off (and cluster it as necessary). But then what?

Oh I guess you would have to make your pipeline to your database really good, then as long as no two objects interacted directly and only through the database, then you could just simply run multiple instances of the game. Then you would need a layer in front… but it would only be to redirect clients to load balance the servers. Then the last part would simply be using the new found 'cloud' api's to bring up or down servers based on demand which would need to be tracked so as not to pay for unneeded servers.

I am meandering a bit, but above is my raw thought process.
0.0/23