Re: Developing from scratch
 

I played AoA a ton over a year ago, and it was definitely something to look at. The game was very playable a year ago, but like any good online game, he was always adding stuff, taking feedback, tweaking, etc.

His stuff is definitely coded from scratch, but I'd say he's an exception to the norm. :)

Re: Developing from scratch
 

Also, while it may not take long to get those basic features out, that still doesn't determine the success of the game. If we're talking about just getting the basics done and enough for a few players to log on, that could be done in a few months or even a few weeks.

I'm definitel not trying to discourage anyone in coding from scratch. I still think it's the best way to go if you're looking to do something new and different or even if you just feel like you need to do it. I just think that things can be very different in practice than in theory.

Re: Developing from scratch
 

The six month time frame mirrors my experience as well. Alter Aeon was online for testing and building after about six months, and I declared it officially open somewhere around 10 months. That's not to say that it was great at 10 months; but it was definitely playable, fun, and had a decent playerbase.

In spite of being a poor college student, I somehow managed to save archives from that time period on floppies, and a few years ago I collected every backup and disk I could find and added them to my permanent archive. Occasionally I'll boot up the november 1995 version and let people play on it so they can see how it's changed over the years. Even for me, its quite a blast from the past.

-dentin

Re: Developing from scratch
 

Good help is hard to find.

I've been wondering if the Wikipedia approach could be used for a MUD server.

Re: Developing from scratch
 

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.

Not all games are equal. One person's MUD completed in a short development period, may only be a small shadow of another's longer term perpetual development project. This is not necessarily a given, but well, when subjective claims are being bandied around who knows.

It is a lot easier to implement something you have implemented before. Even if you are not reusing code, you may simply be reconstructing systems that you have constructed before. Maybe you only worked on it part time, and you implemented a flash client, and you have six kids and two fingers on each hand. Regardless, an achievement of a certain goal does not mean that all achievements of that goal are equal. It maybe be that you develop in flash (is the technical term flashturbate?) professionally.

I don't mean to pick on the poster who the last paragraph attemts to parody in order to highlight the point I was trying to make, it was simply the possibilities that came to mind. The fact is that I could write a game completely from scratch in a week, if I knew ahead of time what I was going to make. The game design, or an existing idea I was going to pretty much adopt. The game systems, or existing ones that I was going to remake.

Fair? Not fair?

Re: Developing from scratch
 

Completely fair. And your entire post is probably what I was getting at. After running NWA for 10 years, I could make another MUD in a few weeks. From scratch? Depends on your definition. Fully operational? Depends on your definition. Is it fun, lame, one line descriptions? Does it matter?

So let's cut to the chase and have a competition. Anyone who wants to prove their competetiveness and super coding abilities create a MUD from scratch (use no other code but what you hand create--no snippets, no cut and pastes from websites) and post a link to your MUD that includes all the source code for review and proof of "scratch" creation.

Winner will be chosen at the end of the three month period based on the quality and playability of the MUD submitted. (Bonafied time stamps showing revision times will be required on your MUD code files to prove they were created during this time period).

Ready...Begin!

Re: Developing from scratch
 

Actually, said poster(SP) has 7 kids, ailing live-in, elderly parents, 3 energetic dogs, a parrot, 3 pet rats and only ONE hand with 2 fingers -- he is missing the other hand altogether. SP was forced to resort to using a special keyboard that allowed toe typing, which of course made his efforts in flashtubation rather difficult. Not only that, but SP had to type uphill both ways while drinking coffee through a straw. Interestingly enough, SP still managed to find that special groove that allowed thoughts to flow from his mind, through his toes, across the keys, and ultimately take the beautiful form of code.


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.

Fair or unfair? I think it's silly to downplay people's achievements. Whether their achievement meets "your" definition is irrelevant. What is relevant, and what should be celebrated, is that people put forth the effort and desire in the first place and actually do something -- something that they can be proud of, whether it be big or small.

Re: Developing from scratch
 

With ConQUEST's lair feature, I'm getting a taste of world-building.
I now have nothing but respect for people that manage to name and describe over 10,000 rooms. O.o

Re: Developing from scratch
 

I don't understand what this means, or what it is referring to. I thought it was a coding related forum, where discussion of coding takes place. To question why it was possible for someone who claims that it is possible to make a MUD in a short period of time to have done so, adds perpective. And it helps those who hope to emulate the achievement know exactly what they would have to do, without a false belief that it is generically possibly for anyone to do it in that time period.

Re: Developing from scratch
 

Eh nothing to understand. I probably was suffering from foot-in-mouth syndrome or something --- it was early and the coffee hadn't set in yet. ;-) Whatever the case, we can certainly start a new thread and regale interested parties with insight on "writing a playable MUD from scratch".

Re: Developing from scratch
 

A problem is that MUDs seem to be very centered around pre-made codebases and code snippets. For example take a look at the 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 , and .

If you look at for example game development literature such as the 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 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.

Re: Developing from scratch
 

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?

Re: Developing from scratch
 

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.

Re: Developing from scratch
 

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.

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

Re: Developing from scratch
 

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 , or Raph Koster's .

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.

Re: Developing from scratch
 

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.

Re: Developing from scratch
 

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.

Re: Developing from scratch
 

I'm afraid I strongly disagree with you, ArchPrime. 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.

Re: Developing from scratch
 

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.

Re: Developing from scratch
 

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.

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?

Re: Developing from scratch
 

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.

Re: Developing from scratch
 

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).

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.

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.

Re: Developing from scratch
 

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.