[Aeran]

Originally Posted by ArchPrime Parodies aside, Noodle's points are valid and spot on. Noodle's thoughts, though, do illustrate some additional requirements needed to really pull something decent out in a short amount of time: prior experience, clearly defined goals, extreme dedication and a thorough understanding of your chosen toolset.

A problem is that MUDs seem to be very centered around pre-made codebases and code snippets. For example take a look at the article section here on TMS: A lot of articles about building and roleplay(unfortunately most of them lacking references) but little to nothing about technical issues. You see the same pattern on Mudbytes, and TMC.

If you look at for example game development literature such as the Game Programming Gems series you notice that there is a lot of techniques covered in such books. As a reader trying to make a game you can use the experience of the programmers who already met the problems you're facing.

It seems there's a lot less MUD specific resources. There's MUD Game Programming but other than that it doesn't look like there's much more. You would have to look at more graphical multiplayer/MMO centered books and articles to draw experience from.

[noodles]

Originally Posted by Aeran A problem is that MUDs seem to be very centered around pre-made codebases and code snippets. For example take a look at the article section here on TMS: A lot of articles about building and roleplay(unfortunately most of them lacking references) but little to nothing about technical issues. You see the same pattern on Mudbytes, and TMC. If you look at for example game development literature such as the Game Programming Gems series you notice that there is a lot of techniques covered in such books. As a reader trying to make a game you can use the experience of the programmers who already met the problems you're facing. It seems there's a lot less MUD specific resources. There's MUD Game Programming but other than that it doesn't look like there's much more. You would have to look at more graphical multiplayer/MMO centered books and articles to draw experience from.

You can make a MUD by simply opening a socket, and writing a handler for whatever comes in on it. I wonder if most scratch developers go wrong by not having a clear idea of the game they want to make and remembering that the game should come first. It is easy to get lost and start work on telnet negotiation, database backends and other forms of technical masturbation.

What forms of experience do you see yourself lacking, that you have to resort to reading general programming articles for the lack of MUD related ones?

[KaVir]

Originally Posted by noodles You can make a MUD by simply opening a socket, and writing a handler for whatever comes in on it.

That's not a mud, it's not even a talker. Of course if all you want is a basic talker you could throw it together in an afternoon, even with a low-level language, but that's not what my posts were addressing.

The original claim I disagreed with was that a very specific established mud (that I won't name) with years of work could be "written from scratch in a few weeks".

My view can be pretty much summarised in three quotes from my earlier posts:

"Creating a mud from scratch can be an enjoyable and rewarding project, but there seems to be a common misconception that it will automatically result in a better game. In fact, the only thing it guarantees is more work. If your main goal is just to create a fun, playable game, I would suggest going with an established codebase."

"...people underestimate how much work it takes to create a fully playable mud from scratch. They'll often view it from a purely technical perspective, without stopping to consider that that's one of the easy parts. As a result you see quite a few people start work on creating a game from scratch, but few who actually succeed."

"Within the context of this thread, we're comparing "starting from scratch" against "using an existing codebase", therefore it makes sense to compare equal feature sets. If you want features X, Y and Z, you need to compare the effort involved in writing them from scratch against the effort involved in downloading and modifying a codebase that has some or all of those features built-in."

If you could tell me exactly what you disagree with, it would make it easier to formulate an appropriate response.

[noodles]

Originally Posted by KaVir That's not a mud, it's not even a talker. Of course if all you want is a basic talker you could throw it together in an afternoon, even with a low-level language, but that's not what my posts were addressing.

I was talking in terms of technical information. The kind of articles you are likely to get in Game Programming Gems (in the post I was responding to) are likely to be that deep a level, not gameplay related. In terms of technical information, once you can open a socket to listen and can accept and read/write to them, that's the basic level of you would need to employ to implement gameplay related code on top.

Originally Posted by KaVir The original claim I disagreed with was that a very specific established mud (that I won't name) with years of work could be "written from scratch in a few weeks". ... If you could tell me exactly what you disagree with, it would make it easier to formulate an appropriate response.

I don't disagree with any of your posts in this thread.

[KaVir]

Originally Posted by noodles I was talking in terms of technical information. The kind of articles you are likely to get in Game Programming Gems (in the post I was responding to) are likely to be that deep a level, not gameplay related.

A fair point. For someone who wants to create a fully playable game from scratch I would generally assume a certain degree of technical skill, and be more inclined to recommend books such as Richard Bartle's Designing Virtual Worlds, or Raph Koster's A Theory of Fun for Game Design.

Originally Posted by noodles In terms of technical information, once you can open a socket to listen and can accept and read/write to them, that's the basic level of you would need to employ to implement gameplay related code on top.

I think it's very difficult to clearly define something as "gameplay related". The vast majority of features will have some impact on gameplay - even the socket code can impact gameplay in some situations, and the pure content (such as monsters and quests) will always be restricted by the underlying mechanics.

[Aeran]

Originally Posted by noodles You can make a MUD by simply opening a socket, and writing a handler for whatever comes in on it. I wonder if most scratch developers go wrong by not having a clear idea of the game they want to make and remembering that the game should come first. It is easy to get lost and start work on telnet negotiation, database backends and other forms of technical masturbation. What forms of experience do you see yourself lacking, that you have to resort to reading general programming articles for the lack of MUD related ones?

There's a lot of things you could look at:
1. Concurrency issues if you decide to use threading.
2. Data structure/flow organization.
3. Command parsing.

I don't think there is anything wrong with starting early with telnet negotiation. If you don't consider the low level issues from the start you can get problems later - e.g if you mistakenly assume that data arrive as one chunk.

[ArchPrime]

Originally Posted by KaVir The original claim I disagreed with was that a very specific established mud (that I won't name) with years of work could be "written from scratch in a few weeks".

In the grand scheme of things(The big, huge picture), I'm not sure there is a code base that will give you much of a head start, if you're looking to match features, original content, and sheer scale. Sure, you can download just about anything from a bit of code that opens a socket to code that nearly represents a full featured game. At that point, though, you've still got the original content to create -- which can potentially take years...and that is only after you completely understand the nuances of whatever nearly full-featured codebase you downloaded -which can easily take weeks to months.

[KaVir]

I'm afraid I strongly disagree with you, ArchPrime. Code reuse is a common software engineering technique, and the subject of considerable research. Do you not make use of existing libraries when developing your mud? That's not much different to using a well-developed codebase or driver.

[Newworlds]

Originally Posted by KaVir I'm afraid I strongly disagree with you, ArchPrime. Code reuse is a common software engineering technique, and the subject of considerable research.

This is 100% true, especially in graphic games where 3D engines are always reused or upgraded from existing engines and ported into the main code.

Though I don't think this was his point. I think Archprime is saying that no codebase is any better than another when deciding what to use to build the foundation of a game. In that case I think he is right except where personal preference or experience would play a role.

[ArchPrime]

Originally Posted by KaVir I'm afraid I strongly disagree with you, ArchPrime. Code reuse is a common software engineering technique, and the subject of considerable research. Do you not make use of existing libraries when developing your mud? That's not much different to using a well-developed codebase or driver.

Uh, ok. Feel free to disagree with me anytime. ;-) I am rather agreeable to that notion. As an aside, I am a long time software developer by trade -- code reuse is certainly part of my vocabulary and practice. However, the act of installing a MUD code-base does not equate to code reuse. I think I'm safe to assume, though, that whomever is doing the install is actually interested in building something, not just merely "installing a game someone else wrote, and running it". And, as such, they will be required to spend time "in" that code base to efficiently reuse its code. That simply does not happen overnight.

Originally Posted by KaVir The original claim I disagreed with was that a very specific established mud (that I won't name) with years of work could be "written from scratch in a few weeks".

I agree with this statement. In my mind, the "established MUD with years of work" would have a HUGE base of content. And, in order to reach the magnitude of an established mud with years of work, you too would have to devote many, many hours to content creation. So many hours in fact, that the act of content creation itself dwarfs the initial effort of either 1). installing and learning a code base or 2). writing a similar featured code base from scratch. That's what I was referring to...

So, what MUD code base is going to give a person a jump start that would allow them to achieve the same magnitude as a well established MUD that's had years of work?

[Aeran]

Originally Posted by ArchPrime I agree with this statement. In my mind, the "established MUD with years of work" would have a HUGE base of content. And, in order to reach the magnitude of an established mud with years of work, you too would have to devote many, many hours to content creation.

From reading the first post of the thread again, I don't think content was included in the statement.

I think what Kylotan tried to point out is that there are other programming languages than C with more well built standard libraries and language features suited for MUD programming. If you were to make some software in C you would have to do almost everything from scratch, including linked lists or binary trees or whatever you want to use.

With Java or C++ you would get a lot of these things for free.

[KaVir]

Originally Posted by ArchPrime However, the act of installing a MUD code-base does not equate to code reuse.

Using existing software as the starting point for a new version is actually a fairly common form of code reuse, and one I've seen to varying degrees in every professional project I've worked on. Even in my own mud, I've reused various standalone snippets that I've written and released in the past (such as my soundex parser, my dynamic description parser, my text justification snippet, etc).

Originally Posted by ArchPrime I think I'm safe to assume, though, that whomever is doing the install is actually interested in building something, not just merely "installing a game someone else wrote, and running it". And, as such, they will be required to spend time "in" that code base to efficiently reuse its code. That simply does not happen overnight.

It depends on what they're using. It could be some low-level functionality that can simply be compiled and used in the same way as a library, it could be an LPMud-style driver with the owner developing within in a sandbox...but even if they decide to modify what they've downloaded, unless it's very poorly written and/or documented it should still be faster than writing it all themselves.

Originally Posted by ArchPrime So, what MUD code base is going to give a person a jump start that would allow them to achieve the same magnitude as a well established MUD that's had years of work?

A copy of that mud, but that's not what we're discussing. The question here is what codebase is going to give someone a faster development time than writing from scratch. And the answer will obviously depend on what they're trying to do - there is no "silver bullet" codebase that'll fix every problem.

[Kylotan]

Originally Posted by noodles I read this thread and see people handwaving that they could, or have, created a MUD from scratch in what others have dismissed as an infeasible amount of time. And two thoughts are raised, firstly what exactly constitutes the MUD they have created, and secondly whether scratch is all it is claimed to be.

The original statement was not that I (or anybody else) could recreate any given game, its rules, and its content, in a very short time. Thus the 'not all games are equal' stuff is a strawman argument. It was about recreating the code equivalent to a typical Diku mud. And if you take a codebase like Merc you can quickly see that most of it is simply not necessary if you use a higher level language to implement the same commands and features. And once you've done that, you have a code base that is far quicker to add new features to than if you stick with one in C where you have to treat strings as arrays and handle all your data structures yourself.