10 Dec, 2008, Tyche wrote in the 21st comment:
Votes: 0
One way to roughly test performance before you buy a VPS might be to run VMWare (or some other virtualization software) on your personal PC just to see how Coffeemud reacts under different memory configurations.
10 Dec, 2008, Kayle wrote in the 22nd comment:
I use Dynadot for domain registrations.
And Uh.. 600Mb of Memory for a MUD? Holy shit. WoW wasn't even using 600MB of memory while I was running it. It was hovering at approx. 4-8% of my 2GB Memory depending on where I was. o.O
And Uh.. 600Mb of Memory for a MUD? Holy shit. WoW wasn't even using 600MB of memory while I was running it. It was hovering at approx. 4-8% of my 2GB Memory depending on where I was. o.O
10 Dec, 2008, The_Fury wrote in the 23rd comment:
Tyche said:
One way to roughly test performance before you buy a VPS might be to run VMWare (or some other virtualization software) on your personal PC just to see how Coffeemud reacts under different memory configurations.
Yeah i was thinking the same thing by using andlinux, installing it with different memory allocations as seeing how coffee mud handles different memory.
10 Dec, 2008, ghasatta wrote in the 24th comment:
Hi,
We use godaddy vps. No real complaints - it does what we need it to, at a cost that is not much more than what you pay for typical mudhosts. You have to be careful when selecting a VPS - many have specific language in their terms of service that prohibit daemons / muds. Godaddy has no such restriction. Physical memory limits are a little less than what you require, you are going to have to decide if the monthly cost is worth your memory consumption.
If we outgrow godaddy the next step for me would be Amazon's Elastic Cloud Compute (EC2) service. It's basically the same thing as running your own VPS, although the actual cost of that would be $80 / mo minimum. Something to consider. :)
Good luck!
We use godaddy vps. No real complaints - it does what we need it to, at a cost that is not much more than what you pay for typical mudhosts. You have to be careful when selecting a VPS - many have specific language in their terms of service that prohibit daemons / muds. Godaddy has no such restriction. Physical memory limits are a little less than what you require, you are going to have to decide if the monthly cost is worth your memory consumption.
If we outgrow godaddy the next step for me would be Amazon's Elastic Cloud Compute (EC2) service. It's basically the same thing as running your own VPS, although the actual cost of that would be $80 / mo minimum. Something to consider. :)
Good luck!
10 Dec, 2008, Orrin wrote in the 25th comment:
I have a VPS with linode and I'm happy with the service. Their admin tools are great and the only down time I've noticed in 6 months was a reboot for a server upgrade.
10 Dec, 2008, Lyanic wrote in the 26th comment:
Quote
I have a VPS with linode and I'm happy with the service.
I can second the recommendation for LiNode. I don't use them now because it's more raw power than my MUD requires (and I got far less expensive service elsewhere), but they have good service at competitive prices. You MIGHT be able to get by with their base package (360mb RAM) at $20/month.
10 Dec, 2008, Davion wrote in the 27th comment:
For a VPS with 600 megs of ram… pretty much no matter where you go, you're looking to pay around $30-$40USD's a month. We use VPSLand here for MudBytes and so far no complaints! We pretty much have 0 downtime except in the event that we need to upgrade. Right now MB's uptime is almost 300 days :D! Supper fast connection that almost never lags and decent support if/when you need it.
When it actually comes to running your own VPS and you know little to nothing about administrating linux, look for a provider that does some form of security for you, as well as backups (just in case you forget.) You have to start somewhere, and on a VPS where you can't really physically harm yourself or your computer, I think you'll do fine. As for domain registrars, I use http://www.dynadot.com. I think though, registrars isn't a big deal. I have little to do with mine past a yearly visit to renew the domains.
When it actually comes to running your own VPS and you know little to nothing about administrating linux, look for a provider that does some form of security for you, as well as backups (just in case you forget.) You have to start somewhere, and on a VPS where you can't really physically harm yourself or your computer, I think you'll do fine. As for domain registrars, I use http://www.dynadot.com. I think though, registrars isn't a big deal. I have little to do with mine past a yearly visit to renew the domains.
10 Dec, 2008, elanthis wrote in the 28th comment:
Davion said:
For a VPS with 600 megs of ram… pretty much no matter where you go, you're looking to pay around $30-$40USD's a month.
TekTonic may be the cheapest solution around. They kinda suck, but they are cheap. I can't imagine why anyone would possibly need 600 MB of RAM for hosting a MUD and corresponding site, though. I can run MySQL, Apache, clamd, spamassassin, dovecot, and Exim for about 20 medium-traffic sites on a single Linode with ~512MB of RAM. You have to know how to tune things, but it works just fine once you do. The biggest performance issue I find with most VPS is actually the disk access speed, due to have a whole bunch of VPS all trying to access different parts of the disk at the same time; hence the most important tuning for a VPS is to eliminate all unnecessary disk reads and syncs. I can't imagine any MUD these days needing even close to 512MB, and a website for a MUD isn't going to have a huge number of visitors, either.
10 Dec, 2008, Cratylus wrote in the 29th comment:
Quote
I can't imagine why anyone would possibly need 600 MB of RAM for hosting a MUD and corresponding site, though.
So everyone is like OMG 600 MEGAQUADS and I'm
like what is so amazing?
I decided to see what it takes for my mud to
load up 100 megs. I have this virtual area
that simulates space and is 2.1 x 2.1 x 2.1
billion rooms per axis, so I figured that's
a pretty good way to see how many loaded rooms
it takes.
I coded a missile that travels X rooms per second
and has a range of Y rooms, so I fiddled with
the settings, teleported myself into outer space,
and launched a missile to see how many
autogenerated rooms it takes to get to 100m.
In my tests it took about 20,000 rooms. Probably
I could get it to load more rooms in less ram,
but my codebase does tend to load a fair amount
of overhead per loaded object, and 100m for 20k
rooms really isn't that surprising. Nor frankly,
is it that horrible. Between browsers, office
applications, etc, my current desktop is prolly
pushing a couple hundred megs right there. Nobody
should bat an eye at that, nor at a busy mud
with actual logged on users that uses resources.
Can I imagine a use for having thousands of
rooms and objects loaded into memory at boot?
Sure. Bots. Stat tests. Player-controlled armies.
It's actually not that hard.
Please let's get off the OMAGAWD ONE POINT
TWENTY ONE JIGGAWATTS and actually focus on the
gentleman's questions.
Quote
For a VPS with 600 megs of ram… pretty much no matter where you go, you're looking to pay around $30-$40USD's a month.
Like I said, I get more than that for $20/mo.
-Crat
http://lpmuds.net
10 Dec, 2008, Lyanic wrote in the 30th comment:
Quote
In my tests it took about 20,000 rooms. Probably
I could get it to load more rooms in less ram,
but my codebase does tend to load a fair amount
of overhead per loaded object, and 100m for 20k
rooms really isn't that surprising. Nor frankly,
is it that horrible.
I could get it to load more rooms in less ram,
but my codebase does tend to load a fair amount
of overhead per loaded object, and 100m for 20k
rooms really isn't that surprising. Nor frankly,
is it that horrible.
I actually said 1mil rooms (which still isn't insanely high if it's procedurally generated) at 600mb. You're saying 120k rooms at 600mb, essentially. And people called me crazy…
I think it's highly plausible, though.
10 Dec, 2008, David Haley wrote in the 31st comment:
Huh. After looking at Crat's empirical numbers, I'm kind of surprised that nobody caught the error in my math earlier. :redface:
Regardless, the question in the end of the day is whether you really need that much memory resident, or if it's ok to swap some/most of it out.
Regardless, the question in the end of the day is whether you really need that much memory resident, or if it's ok to swap some/most of it out.
10 Dec, 2008, Lyanic wrote in the 32nd comment:
Quote
Huh. After looking at Crat's empirical numbers, I'm kind of surprised that nobody caught the error in my math earlier.
I caught the error, but only after I had already posted a follow-up. After that, I felt it foolish to point out a math error I was also culpable for. Good job outing us both! *mutters* ;)
11 Dec, 2008, elanthis wrote in the 33rd comment:
I'm going to continue doubting that 600MB is necessary for a MUD. Even if you have a million rooms, I have to ask why you have them all loaded into memory when you clearly don't have a million players.
Even big graphical games that have huge seamless worlds have this kind of stuff solved – it's not that difficult to deal with for MUDs. In essence, any processing or data that a player cannot directly see is wasted effort. If you have fully NPC armies battling it out on a distant planet, do you _really_ need all the rooms and NPC stats loaded up for that? No, you don't. No player can see it, and hence putting forth a full level of processing is a waste. You can just estimate the entire battle with a greatly reduced set of data, simplified calculations, and so on. 3D games have done stuff like this for a long while, where the large open areas are represented with one rendering engine and the highly-detailed, up-close areas are rendered with another.
The same goes for MUDs that have NPCs that randomly battle. If no PC can see the battle, you don't need to do the full combat stuff. The NPCs meet, just do a quick estimate of power, do one die-roll calculation, let the loser die and let the winner's HP be reduced by some percentage. You don't need full data for a zone that no player is in, especially if no player is even close to getting to said zone. If you have a ton of zones and few players, why keep them all in memory? Save the unused zones to disk and unload it from RAM. When a player follows an exit or a teleport or anything to an unloaded zone, load it up right there. If for some reason zone loading is slow for your MUD (also likely a design problem), then you can load the zone data in a separate thread, putting the player movement into a pending state until the zone is loaded and linked in. NWN – which is like, what, 7 years old? – did this. The entire game was split into just a handful of modules, but the whole module would be active at one time. NPCs within viewing range of any active player had full AI. NPCs far enough outside the viewable range of the player had simplified AI. Maps that no player was in would unload all of the viewable geometry, leaving just the basic navigation info around so NPCs could do their (very simplified) movement and AI calculations. The areas that no player could even reach any time soon were put into deep-sleep mode, unloaded from memory, and NPCs had AI disabled.
The concept has been called "Simulation Level of Detail," taking the term from the Mesh Level of Detail support 3D engines have used for years to reduce the amount of rendering necessary for objects that are not close to the player. You don't need as much detail to represent data that nobody can see as you do for the things that a player is actually observing or interacting with.
Large MUDs can also likely make heavy use of shared data. I very highly doubt that a MUD with 1 million rooms has 1 million unique, hand-written room descriptions. You don't need to store a ton of copies of auto-generated descriptions or objects when you can instead keep a handful of "templates" and then use light-weight objects that reference those templates. Large MUDs are almost certainly already using some kind of template setup to generate all those rooms, so it's just a question of keeping that data in the templates instead of copying it out to a ton of room objects. Even small MUDs should probably be using this technique as often as possible. I can't even fathom why you'd want to keep even those light weight objects around for hundreds of thousands of rooms that no player is even remotely close to, or why you'd want to represent vast amounts of repetitive scenery with a multitude of rooms instead of a coordinate system.
A game is all about the players. It doesn't matter how big of a world you are trying to simulate. If your MUD is using up 600MB for a player base of 60 players, then your game design requires 10MB of data for each player. That's 10 million bytes, just to support the entertainment of one player in a text-based game that can only visualize a few paragraphs worth of game world at a time. No pixmap textures, no sound effects or music, no realistically-detailed meshes… just a big handful of sentences. Heck, even in an MMO, you don't have all that data – the server doesn't need it, only the client does. All the server needs in a graphical game is a highly simplified navigation and collision mesh representing world geometry, and the information needed to represent AI and combat. I'd consider a graphical game that's using 10MB of game world data per player to be a resource hog as well.
Quite simply, if you're using 600MB+ for a MUD, you're doing something wrong. I don't care what your excuse is. You don't need it, you're wasting resources that have no true impact on the actual players, and your code can be improved to greatly reduce your memory usage. You don't need a million full room objects for ANY FREAKING REASON when you've got like 60 players tops. MUDs that try to pull off that stuff are nothing more than the coders' trying to masturbate with a compiler and then brag about who shot out the biggest load.
If you want to pay for a 2GB VPS, fine. That's entirely your call. Just realize that you're wasting a lot of cash solely because your design sucks.
Even big graphical games that have huge seamless worlds have this kind of stuff solved – it's not that difficult to deal with for MUDs. In essence, any processing or data that a player cannot directly see is wasted effort. If you have fully NPC armies battling it out on a distant planet, do you _really_ need all the rooms and NPC stats loaded up for that? No, you don't. No player can see it, and hence putting forth a full level of processing is a waste. You can just estimate the entire battle with a greatly reduced set of data, simplified calculations, and so on. 3D games have done stuff like this for a long while, where the large open areas are represented with one rendering engine and the highly-detailed, up-close areas are rendered with another.
The same goes for MUDs that have NPCs that randomly battle. If no PC can see the battle, you don't need to do the full combat stuff. The NPCs meet, just do a quick estimate of power, do one die-roll calculation, let the loser die and let the winner's HP be reduced by some percentage. You don't need full data for a zone that no player is in, especially if no player is even close to getting to said zone. If you have a ton of zones and few players, why keep them all in memory? Save the unused zones to disk and unload it from RAM. When a player follows an exit or a teleport or anything to an unloaded zone, load it up right there. If for some reason zone loading is slow for your MUD (also likely a design problem), then you can load the zone data in a separate thread, putting the player movement into a pending state until the zone is loaded and linked in. NWN – which is like, what, 7 years old? – did this. The entire game was split into just a handful of modules, but the whole module would be active at one time. NPCs within viewing range of any active player had full AI. NPCs far enough outside the viewable range of the player had simplified AI. Maps that no player was in would unload all of the viewable geometry, leaving just the basic navigation info around so NPCs could do their (very simplified) movement and AI calculations. The areas that no player could even reach any time soon were put into deep-sleep mode, unloaded from memory, and NPCs had AI disabled.
The concept has been called "Simulation Level of Detail," taking the term from the Mesh Level of Detail support 3D engines have used for years to reduce the amount of rendering necessary for objects that are not close to the player. You don't need as much detail to represent data that nobody can see as you do for the things that a player is actually observing or interacting with.
Large MUDs can also likely make heavy use of shared data. I very highly doubt that a MUD with 1 million rooms has 1 million unique, hand-written room descriptions. You don't need to store a ton of copies of auto-generated descriptions or objects when you can instead keep a handful of "templates" and then use light-weight objects that reference those templates. Large MUDs are almost certainly already using some kind of template setup to generate all those rooms, so it's just a question of keeping that data in the templates instead of copying it out to a ton of room objects. Even small MUDs should probably be using this technique as often as possible. I can't even fathom why you'd want to keep even those light weight objects around for hundreds of thousands of rooms that no player is even remotely close to, or why you'd want to represent vast amounts of repetitive scenery with a multitude of rooms instead of a coordinate system.
A game is all about the players. It doesn't matter how big of a world you are trying to simulate. If your MUD is using up 600MB for a player base of 60 players, then your game design requires 10MB of data for each player. That's 10 million bytes, just to support the entertainment of one player in a text-based game that can only visualize a few paragraphs worth of game world at a time. No pixmap textures, no sound effects or music, no realistically-detailed meshes… just a big handful of sentences. Heck, even in an MMO, you don't have all that data – the server doesn't need it, only the client does. All the server needs in a graphical game is a highly simplified navigation and collision mesh representing world geometry, and the information needed to represent AI and combat. I'd consider a graphical game that's using 10MB of game world data per player to be a resource hog as well.
Quite simply, if you're using 600MB+ for a MUD, you're doing something wrong. I don't care what your excuse is. You don't need it, you're wasting resources that have no true impact on the actual players, and your code can be improved to greatly reduce your memory usage. You don't need a million full room objects for ANY FREAKING REASON when you've got like 60 players tops. MUDs that try to pull off that stuff are nothing more than the coders' trying to masturbate with a compiler and then brag about who shot out the biggest load.
If you want to pay for a 2GB VPS, fine. That's entirely your call. Just realize that you're wasting a lot of cash solely because your design sucks.
11 Dec, 2008, Noplex wrote in the 34th comment:
I would have to agree elanthis. Unless you have a steady couple hundred of players online I don't think you should even be pushing anywhere near that. I cannot remember off the top of my head the usage statistics of my old codebase, but I would think that if you are pushing 600MB its time to start thinking about spending a couple of weeks with valgrind and implementing a shared string system.
11 Dec, 2008, David Haley wrote in the 35th comment:
It's not just shared strings. Let's look at numbers (correctly this time)…
Assume 500 bytes per room. 1,000,000 rooms * 500 bytes per room = 500,000,000 bytes. So, a million rooms in memory would use 500 MB. A million rooms is, say, a 1,000x1,000 overland map.
So you need to improve a lot more than just shared strings: you need some kind of system where you don't load up rooms unless you actually have to, which is basically what elanthis was saying.
Designing an on-demand resource management system is a lot harder than just using shared strings. But anybody who wants such huge amounts of content should realize that they can't have their cake and eat it too when it comes to resource usage.
As always, though, it's important to remember that there's a big difference between memory in RAM and the virtual memory of the process…
Assume 500 bytes per room. 1,000,000 rooms * 500 bytes per room = 500,000,000 bytes. So, a million rooms in memory would use 500 MB. A million rooms is, say, a 1,000x1,000 overland map.
So you need to improve a lot more than just shared strings: you need some kind of system where you don't load up rooms unless you actually have to, which is basically what elanthis was saying.
Designing an on-demand resource management system is a lot harder than just using shared strings. But anybody who wants such huge amounts of content should realize that they can't have their cake and eat it too when it comes to resource usage.
As always, though, it's important to remember that there's a big difference between memory in RAM and the virtual memory of the process…
11 Dec, 2008, Lobotomy wrote in the 36th comment:
elanthis said:
I'm going to continue doubting that 600MB is necessary for a MUD. Even if you have a million rooms, I have to ask why you have them all loaded into memory when you clearly don't have a million players.
Even big graphical games that have huge seamless worlds have this kind of stuff solved – it's not that difficult to deal with for MUDs. In essence, any processing or data that a player cannot directly see is wasted effort. If you have fully NPC armies battling it out on a distant planet, do you _really_ need all the rooms and NPC stats loaded up for that? No, you don't. No player can see it, and hence putting forth a full level of processing is a waste. You can just estimate the entire battle with a greatly reduced set of data, simplified calculations, and so on. 3D games have done stuff like this for a long while, where the large open areas are represented with one rendering engine and the highly-detailed, up-close areas are rendered with another.
The same goes for MUDs that have NPCs that randomly battle. If no PC can see the battle, you don't need to do the full combat stuff. The NPCs meet, just do a quick estimate of power, do one die-roll calculation, let the loser die and let the winner's HP be reduced by some percentage. You don't need full data for a zone that no player is in, especially if no player is even close to getting to said zone. If you have a ton of zones and few players, why keep them all in memory? Save the unused zones to disk and unload it from RAM. When a player follows an exit or a teleport or anything to an unloaded zone, load it up right there. If for some reason zone loading is slow for your MUD (also likely a design problem), then you can load the zone data in a separate thread, putting the player movement into a pending state until the zone is loaded and linked in. NWN – which is like, what, 7 years old? – did this. The entire game was split into just a handful of modules, but the whole module would be active at one time. NPCs within viewing range of any active player had full AI. NPCs far enough outside the viewable range of the player had simplified AI. Maps that no player was in would unload all of the viewable geometry, leaving just the basic navigation info around so NPCs could do their (very simplified) movement and AI calculations. The areas that no player could even reach any time soon were put into deep-sleep mode, unloaded from memory, and NPCs had AI disabled.
The concept has been called "Simulation Level of Detail," taking the term from the Mesh Level of Detail support 3D engines have used for years to reduce the amount of rendering necessary for objects that are not close to the player. You don't need as much detail to represent data that nobody can see as you do for the things that a player is actually observing or interacting with.
Large MUDs can also likely make heavy use of shared data. I very highly doubt that a MUD with 1 million rooms has 1 million unique, hand-written room descriptions. You don't need to store a ton of copies of auto-generated descriptions or objects when you can instead keep a handful of "templates" and then use light-weight objects that reference those templates. Large MUDs are almost certainly already using some kind of template setup to generate all those rooms, so it's just a question of keeping that data in the templates instead of copying it out to a ton of room objects. Even small MUDs should probably be using this technique as often as possible. I can't even fathom why you'd want to keep even those light weight objects around for hundreds of thousands of rooms that no player is even remotely close to, or why you'd want to represent vast amounts of repetitive scenery with a multitude of rooms instead of a coordinate system.
A game is all about the players. It doesn't matter how big of a world you are trying to simulate. If your MUD is using up 600MB for a player base of 60 players, then your game design requires 10MB of data for each player. That's 10 million bytes, just to support the entertainment of one player in a text-based game that can only visualize a few paragraphs worth of game world at a time. No pixmap textures, no sound effects or music, no realistically-detailed meshes… just a big handful of sentences. Heck, even in an MMO, you don't have all that data – the server doesn't need it, only the client does. All the server needs in a graphical game is a highly simplified navigation and collision mesh representing world geometry, and the information needed to represent AI and combat. I'd consider a graphical game that's using 10MB of game world data per player to be a resource hog as well.
Quite simply, if you're using 600MB+ for a MUD, you're doing something wrong. I don't care what your excuse is. You don't need it, you're wasting resources that have no true impact on the actual players, and your code can be improved to greatly reduce your memory usage. You don't need a million full room objects for ANY FREAKING REASON when you've got like 60 players tops. MUDs that try to pull off that stuff are nothing more than the coders' trying to masturbate with a compiler and then brag about who shot out the biggest load.
If you want to pay for a 2GB VPS, fine. That's entirely your call. Just realize that you're wasting a lot of cash solely because your design sucks.
Even big graphical games that have huge seamless worlds have this kind of stuff solved – it's not that difficult to deal with for MUDs. In essence, any processing or data that a player cannot directly see is wasted effort. If you have fully NPC armies battling it out on a distant planet, do you _really_ need all the rooms and NPC stats loaded up for that? No, you don't. No player can see it, and hence putting forth a full level of processing is a waste. You can just estimate the entire battle with a greatly reduced set of data, simplified calculations, and so on. 3D games have done stuff like this for a long while, where the large open areas are represented with one rendering engine and the highly-detailed, up-close areas are rendered with another.
The same goes for MUDs that have NPCs that randomly battle. If no PC can see the battle, you don't need to do the full combat stuff. The NPCs meet, just do a quick estimate of power, do one die-roll calculation, let the loser die and let the winner's HP be reduced by some percentage. You don't need full data for a zone that no player is in, especially if no player is even close to getting to said zone. If you have a ton of zones and few players, why keep them all in memory? Save the unused zones to disk and unload it from RAM. When a player follows an exit or a teleport or anything to an unloaded zone, load it up right there. If for some reason zone loading is slow for your MUD (also likely a design problem), then you can load the zone data in a separate thread, putting the player movement into a pending state until the zone is loaded and linked in. NWN – which is like, what, 7 years old? – did this. The entire game was split into just a handful of modules, but the whole module would be active at one time. NPCs within viewing range of any active player had full AI. NPCs far enough outside the viewable range of the player had simplified AI. Maps that no player was in would unload all of the viewable geometry, leaving just the basic navigation info around so NPCs could do their (very simplified) movement and AI calculations. The areas that no player could even reach any time soon were put into deep-sleep mode, unloaded from memory, and NPCs had AI disabled.
The concept has been called "Simulation Level of Detail," taking the term from the Mesh Level of Detail support 3D engines have used for years to reduce the amount of rendering necessary for objects that are not close to the player. You don't need as much detail to represent data that nobody can see as you do for the things that a player is actually observing or interacting with.
Large MUDs can also likely make heavy use of shared data. I very highly doubt that a MUD with 1 million rooms has 1 million unique, hand-written room descriptions. You don't need to store a ton of copies of auto-generated descriptions or objects when you can instead keep a handful of "templates" and then use light-weight objects that reference those templates. Large MUDs are almost certainly already using some kind of template setup to generate all those rooms, so it's just a question of keeping that data in the templates instead of copying it out to a ton of room objects. Even small MUDs should probably be using this technique as often as possible. I can't even fathom why you'd want to keep even those light weight objects around for hundreds of thousands of rooms that no player is even remotely close to, or why you'd want to represent vast amounts of repetitive scenery with a multitude of rooms instead of a coordinate system.
A game is all about the players. It doesn't matter how big of a world you are trying to simulate. If your MUD is using up 600MB for a player base of 60 players, then your game design requires 10MB of data for each player. That's 10 million bytes, just to support the entertainment of one player in a text-based game that can only visualize a few paragraphs worth of game world at a time. No pixmap textures, no sound effects or music, no realistically-detailed meshes… just a big handful of sentences. Heck, even in an MMO, you don't have all that data – the server doesn't need it, only the client does. All the server needs in a graphical game is a highly simplified navigation and collision mesh representing world geometry, and the information needed to represent AI and combat. I'd consider a graphical game that's using 10MB of game world data per player to be a resource hog as well.
Quite simply, if you're using 600MB+ for a MUD, you're doing something wrong. I don't care what your excuse is. You don't need it, you're wasting resources that have no true impact on the actual players, and your code can be improved to greatly reduce your memory usage. You don't need a million full room objects for ANY FREAKING REASON when you've got like 60 players tops. MUDs that try to pull off that stuff are nothing more than the coders' trying to masturbate with a compiler and then brag about who shot out the biggest load.
If you want to pay for a 2GB VPS, fine. That's entirely your call. Just realize that you're wasting a lot of cash solely because your design sucks.
Clearly, Mabus forgot that he needs to ask for your approval on the design of his game before he can ask you for help with finding a host. :rolleyes:
11 Dec, 2008, Lyanic wrote in the 37th comment:
In response to elanthis (not quoting the entire block of text):
While I agree with some of your points in principle, you're making a lot of invalid assumptions. To start with, you're assuming that A. everyone who runs a MUD is a highly skilled programmer and B. every highly skilled programmer who runs a MUD writes his or her game from scratch. This is just not the case. Point A is fairly straight-forward, in that a large number of MUD developers don't have the background in Computer Science/Software Engineering to tackle the types of design challenges you're throwing out. As for point B, nearly everything you covered absolutely relies on a highly object-oriented design. How many MUDs out there are actually object-oriented in design, keeping in mind that there is a difference between being object-oriented in design and shoehorning classes (generally written in C++) into a legacy codebase (generally written in C)? Even my game is guilty of this - not from a lack of skill, but because it would take far too much time out of active development (adding new features and content) to go back and completely redesign the whole underlying structure of the code. I imagine that is the case for a lot of MUD developers, and perhaps part of the reason why there isn't a higher prevalence of MUDs with true object-oriented designs. This is why I stated in point B that you would have to assume the MUD be written from scratch to support everything you're advocating. It is just too demanding, either in terms of skill or time, to even attempt retrofitting all of this into a legacy codebase. Then, there's your point about "wasting" resources. You make this sound as if memory and disk space are rare and precious commodities that must be preserved for the good of human kind. It's not 1988 anymore…
While I agree with some of your points in principle, you're making a lot of invalid assumptions. To start with, you're assuming that A. everyone who runs a MUD is a highly skilled programmer and B. every highly skilled programmer who runs a MUD writes his or her game from scratch. This is just not the case. Point A is fairly straight-forward, in that a large number of MUD developers don't have the background in Computer Science/Software Engineering to tackle the types of design challenges you're throwing out. As for point B, nearly everything you covered absolutely relies on a highly object-oriented design. How many MUDs out there are actually object-oriented in design, keeping in mind that there is a difference between being object-oriented in design and shoehorning classes (generally written in C++) into a legacy codebase (generally written in C)? Even my game is guilty of this - not from a lack of skill, but because it would take far too much time out of active development (adding new features and content) to go back and completely redesign the whole underlying structure of the code. I imagine that is the case for a lot of MUD developers, and perhaps part of the reason why there isn't a higher prevalence of MUDs with true object-oriented designs. This is why I stated in point B that you would have to assume the MUD be written from scratch to support everything you're advocating. It is just too demanding, either in terms of skill or time, to even attempt retrofitting all of this into a legacy codebase. Then, there's your point about "wasting" resources. You make this sound as if memory and disk space are rare and precious commodities that must be preserved for the good of human kind. It's not 1988 anymore…
12 Dec, 2008, Noplex wrote in the 38th comment:
DavidHaley said:
It's not just shared strings. Let's look at numbers (correctly this time)…
Oh absolutely but I was taking into account that most likely its not a custom code base and it would be much more difficult to staple that onto an existing design. I have personally not seen a game large enough that would need some form of area-based culling in order to run the game on shared hosting. What happens if someone finally decides to enter that area? Most of the areas that are loaded and stay loaded are going to be the areas that everyone generally goes into.
Then again I have not worked with a MUD larger then about 150,000 rooms. I guess if you expect your world to be that large it would be nice to have access to your own dedicated host. But I absolutely agree with you–a string table is not going to be the answer; not even a patch.
12 Dec, 2008, Cratylus wrote in the 39th comment:
Quote
Quite simply, if you're using 600MB+ for a MUD, you're doing something wrong. I don't care what your excuse is. You don't need it, you're wasting resources that…
Please replace the 600MB with 100MB, or 50MB, or really any
number that anyone will find to be excessive. Indeed, let's
examine the term "need" in the context of an online game.
Apparently some sort of nerve has been hit here. I'm sensing
real outrage and shocked disbelief. Your codebase doesn't
run this way. Fine. Mabus's does. He's chosen to keep using
it this way despite what you feel to be wrongness.
What does your fulmination achieve? If he's determined that
this ram use is acceptable to him, what do you care? All this
huffing and puffing is just weird to me. For whatever reason
he's chosen to run this way. It doesn't require an "excuse",
that's what he's decided to do. Maybe his codebase is so awesome
in other ways that it's ok for him. I rather suspect that is
so. Maybe he has reasons he just doesn't feel like sharing.
I'm a results guy. His mud has users. He wants to keep doing
what has succeeded thus far. I'm disinclined to disagree with
his success. He has asked for advice on how to keep doing that
thing. Unless you're going to actually profile his memory use, maybe
you could just, you know, give him credit for having considered this
stuff and give him the courtesy of not assuming he's wrong
regardless of "excuse".
Jeepers creepers.
-Crat
http://lpmuds.net
12 Dec, 2008, The_Fury wrote in the 40th comment:
Cratylus said:
I'm a results guy. His mud has users. He wants to keep doing
what has succeeded thus far. I'm disinclined to disagree with
his success. He has asked for advice on how to keep doing that
thing. Unless you're going to actually profile his memory use, maybe
you could just, you know, give him credit for having considered this
stuff and give him the courtesy of not assuming he's wrong
regardless of "excuse".
Jeepers creepers.
-Crat
http://lpmuds.net
what has succeeded thus far. I'm disinclined to disagree with
his success. He has asked for advice on how to keep doing that
thing. Unless you're going to actually profile his memory use, maybe
you could just, you know, give him credit for having considered this
stuff and give him the courtesy of not assuming he's wrong
regardless of "excuse".
Jeepers creepers.
-Crat
http://lpmuds.net
I actually agree with this sentiment, well spoke Crat.
Random Picks
