26 Jun, 2010, donky wrote in the 1st comment:
Votes: 0
I want to work on my codebase, but one of the things stopping me is how complex it is getting. Working on it has become too much work. I consider the design to be elegant to the extent that it as a work in progress can be, based on adoption of concepts seen elsewhere, experience in previous codebases or a combination of both. Abstraction and decoupling has allowed removal of inherent complexity, but at the expense of adding the other kind of complexity that the structure they impose on the code causes.

Whenever I consider working on it, I feel like it can be a lot more straightforward and simple. But on the other hand..

VT-100 escape codes, text colouring, telnet negotiation, telnet protocols, MUD-specific telnet protocols, telnet-based access, web-based access through COMET, web-based access through websockets, flash clients, database backends, code reloading, unicode character sets, non-unicode character sets, MUD game-related code, integrated web/ftp servers and more.

There's a lot to MUD development these days. You could say "let's just open a port and make a game" but that doesn't cut the mustard any more. These things aren't meaningless, and serve to either enhance the gameplay in some way or streamline its development. The code behind a MUD can have a lot to it, over and above the code that implements the actual game design.

Writing this, two possible avenues to explore occur to me.

1) Decoupling functionality out of the game framework, rather than within it. Specifically, moving code out of the framework and into libraries, then looking at how the internal decoupling and layers of abstraction within the framework can be reduced because of this.

2) Removing object orientation. Rather than letting code fall into natural layers of inheritance, looking at what is accomplished by it being object oriented and the demands this enforces on the systems that work with it.

Has anyone else been in this situation? How have you simplified your codebase?
26 Jun, 2010, Littlehorn wrote in the 2nd comment:
Votes: 0
I don't think average MUD development is complicated at all. I guess it depends on what codebase you are using and the development pipeline you follow. For me, I use QuickMUD (ROM) for most of my projects. I feel it's a stable stock codebase with existing features I love to use for my stock games. I spend less time ripping things out to start my project than adding new things in. Then maintaining it is very simple depending on how complex I make the backend of my game.

Out the box, I simply download QuickMUD, unzip, compile and put it on the desired port I want to run the game on. It takes less than 5 minutes to do all of that. It's up and running unless their our issues on my servers end or human error on my end. From there, I'm ready to begin my production phase to the game.

Majority of my projects start in UltraEdit under a new project file and a copy of my codebase source to start the build cycle. I setup my FTP and Putty within UltraEdit to speed up the development process. Everything I do is either in UltraEdit, Mud Client or Word/Excel. I consider this very fast and easy for me to maintain as my hobby.

This as well what you mentioned is all very light compared to developing and maintaining a full scale online 3D game such as an MMOG. Anything else may just be unwise choices to perfect something beyond the time you need to spend on your project.

Additionally, many admins make the mistake of overloading their projects down with features they either can't support or have the time to finish. Games are not designed with a million hot features you want to add to your game. You must sit down the decide on X amount of features or changes during Y amount of time and stick with it. If you try to add all the bells and whistles to your game then you might find yourself in a bad bind trying to add all of these bells and whistles to your game where it never sees the light of day.

A wise man once said that you shouldn't plan 2 years ahead or even 1 year ahead. Success was made by simply thinking 2 weeks ahead and nothing more.
26 Jun, 2010, quixadhal wrote in the 3rd comment:
Votes: 0
donky said:
VT-100 escape codes, text colouring, telnet negotiation, telnet protocols, MUD-specific telnet protocols, telnet-based access, web-based access through COMET, web-based access through websockets, flash clients, database backends, code reloading, unicode character sets, non-unicode character sets, MUD game-related code, integrated web/ftp servers and more.

There's a lot to MUD development these days. You could say "let's just open a port and make a game" but that doesn't cut the mustard any more. These things aren't meaningless, and serve to either enhance the gameplay in some way or streamline its development.


This is why I've been arguing for years that if MUD developers want to seriously leave the cradle and start making text games for a wider audience, they'll need to abandon the rigid mentality that forces 7-bit TELNET compatibility and 16-colour ANSI graphics. TELNET wasn't chosen as the standard (and a poorly followed one at that!) for MUDs because it was the best choice for the job, it was chosen because you could get away with not actually following it, and because back in 1988, every machine that was likely to be on the internet had telnet available. Compiling a client wasn't a task most players could accomplish (even CS students might not have enough CPU quota or disk quota).

donky said:
Writing this, two possible avenues to explore occur to me.

1) Decoupling functionality out of the game framework, rather than within it. Specifically, moving code out of the framework and into libraries, then looking at how the internal decoupling and layers of abstraction within the framework can be reduced because of this.

2) Removing object orientation. Rather than letting code fall into natural layers of inheritance, looking at what is accomplished by it being object oriented and the demands this enforces on the systems that work with it.

Has anyone else been in this situation? How have you simplified your codebase?


It sounds like you're at the point where you've outgrown the all-in-one design that Dikurivatives have made popular, and want a driver/mudlib seperation such as LpMUD and TinyMUSH use. Fancy terms aside, decide what you want to accomplish. Do you want to write a game, or do you want to write a game development platform? Those are two very different tasks.

If you want to write a game, I'd suggest choosing an existing platform that gives you that driver/game-lib seperation and learn how to make it do what you want it to do. Re-inventing the wheel is fine, but when you try to re-design the car from the wheel up, most people get about as far as the frame with the wheels and the axels, and that's it.

If you want to make a game platform, take a look at what others have done before you and see what concepts you like, and what fits in with your own ideas. Figure out your goals there… are you writing a driver that will provide resource management and security, letting the user write their own mudlib to build a game inside? Are you writing a driver that has game utility systems and expecting them to compile game logic into it? Another option is to use an existing driver and write a mudlib from scratch.

From what you've written, it sounds like you already have a hand-built driver somewhere between the complexity of SocketMUD and NakedMUD. What about it isn't doing what you set out to accomplish? Abstractly saying the design is messy and could be improved is something that's true of just about every system out there. ;)

In my case, I have an antique DikuMUD which has no abstraction or object orientation. It did have several redesign passes back when I was actively developing it. Typically, whenever I found myself writing something that was 90% like something else, I'd start refactoring stuff. I also have an LpMUD that I'm still learning, so while I change systems from time to time, I haven't tackled anything large enough to require any kind of real redesign.
26 Jun, 2010, Fizban wrote in the 4th comment:
Votes: 0
Littlehorn said:
I don't think average MUD development is complicated at all. I guess it depends on what codebase you are using and the development pipeline you follow. For me, I use QuickMUD (ROM) for most of my projects. I feel it's a stable stock codebase with existing features I love to use for my stock games. I spend less time ripping things out to start my project than adding new things in. Then maintaining it is very simple depending on how complex I make the backend of my game.

Out the box, I simply download QuickMUD, unzip, compile and put it on the desired port I want to run the game on. It takes less than 5 minutes to do all of that. It's up and running unless their our issues on my servers end or human error on my end. From there, I'm ready to begin my production phase to the game.

Majority of my projects start in UltraEdit under a new project file and a copy of my codebase source to start the build cycle. I setup my FTP and Putty within UltraEdit to speed up the development process. Everything I do is either in UltraEdit, Mud Client or Word/Excel. I consider this very fast and easy for me to maintain as my hobby.

This as well what you mentioned is all very light compared to developing and maintaining a full scale online 3D game such as an MMOG. Anything else may just be unwise choices to perfect something beyond the time you need to spend on your project.

Additionally, many admins make the mistake of overloading their projects down with features they either can't support or have the time to finish. Games are not designed with a million hot features you want to add to your game. You must sit down the decide on X amount of features or changes during Y amount of time and stick with it. If you try to add all the bells and whistles to your game then you might find yourself in a bad bind trying to add all of these bells and whistles to your game where it never sees the light of day.

A wise man once said that you shouldn't plan 2 years ahead or even 1 year ahead. Success was made by simply thinking 2 weeks ahead and nothing more.


Looks like a gross over-simplification. Most successful MUDs are not just stock with a few extra features slapped on. MUD I work on is quite likely older than some of this site's posters and its .cpp/.h files alone combine to be 4.66 MB, to put this in perspective, the stock codebase's .c/.h files were only 1.18 MB.

Development process as well is more complex than you're describing since we have four coders and all changes are made via svn.
26 Jun, 2010, KaVir wrote in the 5th comment:
Votes: 0
quixadhal said:
This is why I've been arguing for years that if MUD developers want to seriously leave the cradle and start making text games for a wider audience, they'll need to abandon the rigid mentality that forces 7-bit TELNET compatibility and 16-colour ANSI graphics.

There's a lot you can do with a feature-rich mud client - not just more colours, but also proper graphics and sound. However that doesn't mean you have to actively remove support for older clients.

I would lose quite a few players if I forced them to change client. Much more effective to lure them over slowly with pretty screenshots.
26 Jun, 2010, Runter wrote in the 6th comment:
Votes: 0
KaVir said:
quixadhal said:
This is why I've been arguing for years that if MUD developers want to seriously leave the cradle and start making text games for a wider audience, they'll need to abandon the rigid mentality that forces 7-bit TELNET compatibility and 16-colour ANSI graphics.

There's a lot you can do with a feature-rich mud client - not just more colours, but also proper graphics and sound. However that doesn't mean you have to actively remove support for older clients.

I would lose quite a few players if I forced them to change client. Much more effective to lure them over slowly with pretty screenshots.


Reverse compatibility is fine. But I agree with Quix. How many players are we talking about? I'd wager a petty number. No offense. All muds pretty much deal with petty numbers. Even the more successful ones. To break through and reach a broader audience, as Quix is saying, we'd be dealing with thousands of players by my definition. I also understand some type of loyalty to old players, but ultimately if you had to shed the reverse compatibility to reach that broader audience there's other options. Like having a "classic" version that you don't maintain for these folks.
26 Jun, 2010, Littlehorn wrote in the 7th comment:
Votes: 0
Fizban said:
Looks like a gross over-simplification. Most successful MUDs are not just stock with a few extra features slapped on.


Course, I wasn't trying to say stock MUDs are successful. I was saying that when you start becoming feature heavy then that's when you start to over complicate the project. You have to know your limits on what you want your game to accomplish even down to the tools used to develop it.

Fizban said:
MUD I work on is quite likely older than some of this site's posters and its .cpp/.h files alone combine to be 4.66 MB, to put this in perspective, the stock codebase's .c/.h files were only 1.18 MB.


That really doesn't mean anything. Most MUDs don't utilize a lot of today's standards. My MUD is about 6 years old now and it's just my hobby. The source alone is more than likely smaller than 4.66 MB but it's not stock either. That's only because I integrated a lot of my data into a database as opposed to hard coding everything like most bases. But then again, my MUD is built to be small and arena-like with only 3 areas.

Fizban said:
Development process as well is more complex than you're describing since we have four coders and all changes are made via svn.


I can see that, but even that is not complicated at all. I work alone and my production pipeline is designed around one man. Either one of these processes doesn't make the project complicated unless you don't know how to manage a team or the project itself. That's why I mentioned features and maybe reducing your iterations down to 2 week runs much like a good bulk of development is adapting with the Agile methodology.

Everything else is just eye candy.

Runter said:
Reverse compatibility is fine. But I agree with Quix. How many players are we talking about? I'd wager a petty number. No offense. All muds pretty much deal with petty numbers. Even the more successful ones. To break through and reach a broader audience, as Quix is saying, we'd be dealing with thousands of players by my definition. I also understand some type of loyalty to old players, but ultimately if you had to shed the reverse compatibility to reach that broader audience there's other options. Like having a "classic" version that you don't maintain for these folks.


I don't understand what you're saying here. Do you mean that you feel a low percentage of his base would not leave if he forced them into a new client? I think they would just because his existing players are already use to what they play on now. I would more than likely quit his MUD myself if I had to use something else other than the client I use for every game that I play.

Most big MUDs or online games don't focus on the large numbers as much as you think. It's more about how sticky players are coupled with the large numbers. The game doesn't benefit from having 20,000 inactive players who rarely log on the game. They only really benefit from the 5,000 who are always logged on showing the game is alive and popping. Those are the players you want to keep happy and everyone else is the players you want to win back. Would a shiny new client win back those players? Maybe not… That's something to expanding the scope more (as you said already) without forcing your dedicated players to switch. It's a huge risk in an existing game such as KaVirs.

I think you have a lot more to think about than assuming some new client that displays your MUD better is going to open up a new flood of players to your MUD. You can't just jump on a market and say, "build this and they will come" based on some gut feeling. You have to first do some research and find out why so many online gamers don't actually play this specific genre over other genres like say MMOG versus MUD. Although you may say it's because of the graphics, sound or whatever, nothing you make for your client is really going to touch MMOG's in the first place. Coming close to it may help, but then again it's only a gut feeling to begin with.

It's good to think about that stuff. Don't take this as me saying it's useless. I just think it's better to understand that maybe a client is not the only reason players play a MUD.
26 Jun, 2010, KaVir wrote in the 8th comment:
Votes: 0
Runter said:
To break through and reach a broader audience, as Quix is saying, we'd be dealing with thousands of players by my definition.

Step 1: Drop support for existing mud clients.

Step 2: Invent the ultimate new mud client.

Step 3: Thousands of new players start pounding at your door and camping in your garden.

You'll have to elaborate on step 2 if you want to convince me. Right now it sounds suspiciously like one of those "ultimate mud" pipedreams.
26 Jun, 2010, Runter wrote in the 9th comment:
Votes: 0
KaVir said:
Runter said:
To break through and reach a broader audience, as Quix is saying, we'd be dealing with thousands of players by my definition.

Step 1: Drop support for existing mud clients.

Step 2: Invent the ultimate new mud client.

Step 3: Thousands of new players start pounding at your door and camping in your garden.

You'll have to elaborate on step 2 if you want to convince me. Right now it sounds suspiciously like one of those "ultimate mud" pipedreams.


I don't think I have to elaborate. Anything short of thousands of players in the internet age for a game that takes years to develop is fail.

I guess by reaching the wider audience you had 15 people in mind?
26 Jun, 2010, Littlehorn wrote in the 10th comment:
Votes: 0
Runter said:
KaVir said:
Runter said:
To break through and reach a broader audience, as Quix is saying, we'd be dealing with thousands of players by my definition.

Step 1: Drop support for existing mud clients.

Step 2: Invent the ultimate new mud client.

Step 3: Thousands of new players start pounding at your door and camping in your garden.

You'll have to elaborate on step 2 if you want to convince me. Right now it sounds suspiciously like one of those "ultimate mud" pipedreams.


I don't think I have to elaborate. Anything short of thousands of players in the internet age for a game that takes years to develop is fail.

I guess by reaching the wider audience you had 15 people in mind?


If you look at it that way then it's a waste of time. You better off focusing on the current market and pulling players away from your competition rather than trying to pull new players into the market. That does sound like a better bet considering how cheap it is to play more graphically intensive games that you have no way of competing with on the same level for PC and now console.

Then the question becomes: does a hot new client pull more players to your MUD from other MUDs? How many players like to play on their own clients versus custom clients provided by the MUD ?
27 Jun, 2010, Runter wrote in the 11th comment:
Votes: 0
Quote
Then the question becomes: does a hot new client pull more players to your MUD from other MUDs? How many players like to play on their own clients versus custom clients provided by the MUD ?


I think focusing on existing players isn't a good plan if someone wants to be successful. There just aren't enough of them to make the difference. Again, it depends on what someones goal is. Is the goal to get 15 more players or 1500 more? If the goal is to get 15 more players then focusing on existing mud players might be fine. My thought on the subject is that most games out there don't let people bring generic clients to connect to it. Why is it unreasonable for us? It may be unreasonable for us if we're trying to cater to the small group of established mudders. Which is fine, if that's what you're wanting to do. If you're wanting to bring people into the game that have no experience with mudding you need compelling marketing and a great product. Or rather, an accessible product for people who know nothing about it. Personally I find it very unappealing as a long time competitive mmoer to think that people could come into the game with various clients that gives different edges to the game. I'd much rather everyone need to come into the game with the same, albeit customizable, client. I also think our rigid focus on remaining in a dying genre isn't good.
27 Jun, 2010, KaVir wrote in the 12th comment:
Votes: 0
Runter said:
I don't think I have to elaborate.

So your proposal is that just by dropping support for existing clients, thousands of new players are going to suddenly appear to replace the few hundred I've just blocked, hammering at the doors and wanting to play?

No, I'm afraid I'm not convinced. But by all means, go ahead with your own project, I'll be interested to see how it works out.
27 Jun, 2010, Scandum wrote in the 13th comment:
Votes: 0
At the end of the day a MUD is a text game, and as such it appeals to a small crowd. Turning your MUD into a crappy graphical game isn't going to draw in the crowds either.

I think MUDs should focus on blind gamers, even though a blind gamer looking for a blind friendly game is unlikely to find a MUD using google. Additionally, a big downside of graphical interfaces is that it gives sighted players an even greater advantage, though I think MSDP could be used to benefit blind gamers as well.

On topic, decoupling is probably the way to go to keep things manageable, and it also allows others to contribute without having to know the whole codebase. Ultimately I think one man projects are doomed to stagnate and fall behind, Tyche tried to create a modular framework some years ago, but I don't think it ever got passed the design phase.
27 Jun, 2010, Fizban wrote in the 14th comment:
Votes: 0
Runter said:
Then the question becomes: does a hot new client pull more players to your MUD from other MUDs? How many players like to play on their own clients versus custom clients provided by the MUD ?


Can't speak for everyone, but I personally at least would much rather play a MUD where I use my own client than one that they provide for me to use and restrict me to using.
27 Jun, 2010, Runter wrote in the 15th comment:
Votes: 0
KaVir said:
Runter said:
I don't think I have to elaborate.

So your proposal is that just by dropping support for existing clients, thousands of new players are going to suddenly appear to replace the few hundred I've just blocked, hammering at the doors and wanting to play?

No, I'm afraid I'm not convinced. But by all means, go ahead with your own project, I'll be interested to see how it works out.


I'm not trying to convince you of anything. But I'd like to know what your goal is. It sounds like you're just trying to say it can't be done (get more than a hand full of player). I don't believe that at all. The only reasons it can't be done are the same ones the mudding community aren't willing to give up on. Like dumb-client dependency.
27 Jun, 2010, Runter wrote in the 16th comment:
Votes: 0
Fizban said:
Runter said:
Then the question becomes: does a hot new client pull more players to your MUD from other MUDs? How many players like to play on their own clients versus custom clients provided by the MUD ?


Can't speak for everyone, but I personally at least would much rather play a MUD where I use my own client than one that they provide for me to use and restrict me to using.


Yeah. But that kinda fits into what I said. Attracting mudders vs attracting non-mudders. How many gamers expect to get what is basically a MMO experience and bring their own client to play? From the non-mudders I've tried to get interested in mudding over the years they almost always want a solid portal. Their eyes glaze over when you start talking about clients and IP addresses and ports. Sure, maybe the type of players you want are savvy. I can't begin to guess what your goals really are.
27 Jun, 2010, Littlehorn wrote in the 17th comment:
Votes: 0
Runter said:
Quote
Then the question becomes: does a hot new client pull more players to your MUD from other MUDs? How many players like to play on their own clients versus custom clients provided by the MUD ?


I think focusing on existing players isn't a good plan if someone wants to be successful. There just aren't enough of them to make the difference. Again, it depends on what someones goal is. Is the goal to get 15 more players or 1500 more? If the goal is to get 15 more players then focusing on existing mud players might be fine. My thought on the subject is that most games out there don't let people bring generic clients to connect to it. Why is it unreasonable for us? It may be unreasonable for us if we're trying to cater to the small group of established mudders. Which is fine, if that's what you're wanting to do. If you're wanting to bring people into the game that have no experience with mudding you need compelling marketing and a great product. Or rather, an accessible product for people who know nothing about it. Personally I find it very unappealing as a long time competitive mmoer to think that people could come into the game with various clients that gives different edges to the game. I'd much rather everyone need to come into the game with the same, albeit customizable, client. I also think our rigid focus on remaining in a dying genre isn't good.


Most games as in MUDs? If you means MUDs then that's incorrect. There are far more MUDs that do allow generic clients to connect to the game than anything else. The only question is what's the average amount of active player ratio between those who do and don't. I would assume you don't have those metrics.

The problem is that you think, have no solid facts, that unifying a game client is going to bring a large amount of people to a game. You're assuming that it's a bottleneck for new players and experiencing MUD when in fact it may not be the client at all. It could just be the fact it's a text based game with limited 2D support and limited audio that discourages them from playing MUDs outside of other games or online games on the PC or console.

On top of that, you're labeling the entire MUD market as something that's small and not worth targeting for other MUD admins. You keep pushing that you should maybe target something outside of the current market to pull new players into this existing market because that's the best step when in fact it's not. The MUD market is rather large although it is indeed dying. That should be the BEST reason on why you should focus on the current market as opposed to something that's tragically going to be impossible for you to compete with as say the MMO market. You want to keep what MUDDERS that are left sticky in all the thousands of games around the world because they already enjoy MUDDing today. If they leave tomorrow because you were soooo busy focusing on other markets then you may kill off the genre all together because you thought it was a bright idea to screw the current market and target something else that you more than likely wont have any success in achieving.

It's a stupid mistake to not target the thousands of players who play other MUDs in the genre. From a far it doesn't seem like that many players now a days, but to your MUD, if you consumed at least 20 games you may take a large bulk of MUDDers from other games to play on your game; we're all competitors. KaVir, Me, and whoever else have players and they can all switch from our games to your games, or play both games as once.

P.S

You shouldn't pretend to know what the market will do without solid research. It's completely void.
27 Jun, 2010, Oliver wrote in the 18th comment:
Votes: 0
There would be something to be said for creating your own MUD client that only works with your own game and excludes every other client.

The thing is, that'll only help if it's better than every other MUD client in existence. If it's even marginally shittier than MUSHclient, zMUD, cMUD, tintin++, et cetera, no one would even give using it a second thought. Unless your MUD was better than every other MUD in existence.

… good luck with that!
27 Jun, 2010, KaVir wrote in the 19th comment:
Votes: 0
Runter said:
I'm not trying to convince you of anything. But I'd like to know what your goal is. It sounds like you're just trying to say it can't be done (get more than a hand full of player).

I agree that targeting players outside of the mud community is a good idea. What I have strong doubts about is that it's necessary to exclude existing clients in order to do so.

What functionality do you think could be gained by moving away from telnet? What features could such a client offer that can't be done with telnet? And would these enhancements be within the scope of a primarily text-based indie game?

Runter said:
From the non-mudders I've tried to get interested in mudding over the years they almost always want a solid portal. Their eyes glaze over when you start talking about clients and IP addresses and ports.

You see, I can agree with this too. I think it's well worth offering players a custom/ised client that they can use with as little installation and setup as possible - but several muds are already doing exactly that, offering graphics and sound without giving up support for old clients. I don't ever recall hearing someone say "I'd really love to add X to my client, but sadly that's not possible using telnet".

In regard to the size of the current mud community, MudStats reports a peak (across its 790 listed muds) of nearly 10,000 simultaneous players. This is obviously only a very approximate number, but it does at least give us a little context.
27 Jun, 2010, KaVir wrote in the 20th comment:
Votes: 0
Oliver said:
There would be something to be said for creating your own MUD client that only works with your own game and excludes every other client.

In terms of effort perhaps - it's less work to support a single client (when developing a mud) or single mud (when developing a client). But you'll get more people using your client if they can also use it to connect to other games, and more people playing your mud if they can also connect to it with other clients. Otherwise you'd see more deals between server and client developers, to market their two products as a single game.

Annual client downloads:

MUSHclient: 56,438
CMUD: 53,922
zMUD: 52,962
TinTin++: ~20,000
Mudlet: ~12,000

How many downloads do you think there would be if each of those clients could only connect to a single mud?

Likewise, check out the client usage statistics for Aardwolf or God Wars II, and imagine what impact there would be if only one of those clients were able to connect.

Oliver said:
The thing is, that'll only help if it's better than every other MUD client in existence. If it's even marginally shittier than MUSHclient, zMUD, cMUD, tintin++, et cetera, no one would even give using it a second thought. Unless your MUD was better than every other MUD in existence.

It comes back to that old issue of familiarity - different people have different tastes. No matter what your client offers or looks like, some people won't want to give up their current client, and forcing them will just mean they won't even give your game a chance. Even if you had the mythical "best mud in existence", many people aren't going to bother finding that out if you block them at the door.

People may tolerate an interface they don't like if the game is good enough, but there will always be some people for whom the client will be the dealbreaker.
0.0/64