I'm responding like someone disputing nonsense.


Here's what he actually said before trying to rewrite history:


Fine. He likes a specific IDE. Fine. He doesn't want to use vim. Anyone who takes this nonsense without actually pointing out that there's PLENTY of quality IDEs in linux would be doing nobody here a service. Oh, and the BS about realtime debugging in vs studio vs "keeping your stack-dump", that too.

He never said there weren't IDE's for Linux. He said he preferred Visual Studio.

I would +tag "pissing contest" but one of yall would probably just delete it. A damn shame.

Let me provide a summary: windows isn't nearly as bad these days as its (previously valid) reputation. Linux has a lot of benefits for running a mud, but it's clearly not the only option.

Thread over. Kthxbai.

He was comparing linux to windows using a specific IDE as a tool for argument. Putting it up against command-line tools. If you can't see the difference here, you're hopeless.

Maybe he, like me, doesn't have access to any part of linux but the command line?

Once again, Runter, Your word is law, and you can't be wrong. So whatever. Keep tooting your horn, man.

Yet it's a thread discussing developing in windows for windows. Not about different IDEs. He's presenting his argument based on why someone might want to develop for windows. You, on the other hand, develop for the linux platform on windows because of your own admission you don't "have access to any part of linux but the command line". That's all fine and dandy. But this thread wasn't ever about IDEs vs command line, or IDEs vs IDEs. He's the one who brought up liking windows because of a specific IDE while comparing it to a command-line tool.

But the more interesting thing here is you, bringing in personal attacks into this thread without being able to back up anything you say other than to use more personal attacks. The fact that you develop for linux on (presumably) visual studio makes my point for me. You CAN use visual studio and develop for linux, apparently.

But most people would say that's just dumb. ;)

This statement is very shaky. Let me rewrite this slightly:

"If all you know is X, then there's nothing wrong with finding ways to make things work with it."

There are in fact many things wrong with trying to make your hammer work with everything because all you want to use is a hammer. There are times when some things are simply better than others. If it takes less time to use the appropriate tool than it takes to coerce your current tool into working with a problem it wasn't meant to solve, then you are not using your time efficiently at all. And arguably that is definitely "something wrong" with this approach.



And yes, the sentence about stack-dump debugging vs. real-time debugging was not written clearly at all if you weren't trying to imply that gdb didn't do real-time debugging. The way it was written, it was very strongly creating an opposition between gdb's supposed stack-dump-debugging only and VS's real-time debugging.

Arguments about IDE's and debuggers are all well and good, but the core of the issue I was addressing was stability. Now, if you are running a server edition of a Microsoft OS, such as Windows Server 2003 or 2008, *AND* you use that installation as a server, I'm sure it's quite stable and reliable. By that, I mean you don't also sit at the console and use it as a desktop, but rather you let it sit in the corner and be a server, only accessing the console if you need to install or fix something.

That is NOT what the majority of people trying to run muds under windows do.

Most people wanting to run a mud under windows, do so because they have a windows machine they use for gaming, and for their day-to-day desktop web-surfing, light business apps, what-have-you. THOSE windows environments are usually anything but stable. Attempting to run a mud that is open to the public on such a system is asking your players to suffer loss of service whenever you decide to fire up Halo 4, or when Microsoft releases an urgent system update and forces a reboot, or any number of random events that might cause a driver issue.

For THAT reason, I always suggest that people wanting to seriously work on a mud, either get themselves an old piece of hardware from their school/neighbor/junkyard that is being thrown away, and install linux on that – or at least develop in a proper VM with linux installed on it. Why a VM? Well, you want that seperate hardware for your production mud. If it's sitting in the corner on your LAN, or if it's hosted by someone else… either way, it's not anywhere near your gaming machine. But if you do have it hosted, it's often easier to work on things in a VM to test/debug/design, and then upload the working results to your real hardware.

This would also allow you to use a visual IDE if you so desired, even if your real mud is only accessible via ssh or ftp.

Now, if you can find a way to use Visual Studio to work on your dev copy, and have it still compile under your unix host, and not manage to muck up the line endings of your files… that's the best of both worlds.

I have a box with Fedora 12 installed. I tried using Nick Gammon's TinyMud server as it is written in C++. My problem is that I have been a Microsoft guy since DOS. Linux might as well be Kanji to me.

I spent 10 minutes figuring out how to change directories in the Fedora Terminal. Once I got to the TinyMud directory I used the "make" command and received some errors. I had to add some include files into the code and then used "make" again and this time I had no errors but nothing else happened. I noticed a new application inside the TinyMud folder but clicking on it did nothing. I tried to connect to my localHost with the default port and got nothing. I guess I just need a Linux book and/or some more time to get acquainted with Linux.

The other option I tried was the "SimpleMud" that comes with Ron Penton's mud book. When I compile it on Windows with VS 2008, I get 350+ errors and even more warnings. I am still a novice programmer and I am not sure where to begin on the errors. In time, perhaps I can rebuild the whole program, although it is more than I originally set out to do.

I found a codebase called BabelMud - I believe Mr. Haley has something to do with it, but it does not look complete as I could not find a download.

Ultimately I will keep messing with the code in some project; I just thought there might be a more simple solution to finding a working c++ server for windows.

Thanks for the suggestion about ROM. I will look into it.

I don't want any part of a windows / linux war, i could give less of a crap.
I admit the gdb comment was unclear, I didn't sleep enough last night so pardon me.

That aside,

I wish some of the posters were more open minded to what the OP is trying
to get out of this forum. I respect others views although I may not agree with them.
I'm not saying that you can't post your thoughts on the matter, I'm just sick of having
to be on the defensive every time I bring up some sort of Microsoft product.

That aside,

This is a Windows based thread. I'm not seeking out Linux users and trying to convert them.
If you recall, my main point was that I prefer MSVS, but I also like linux, and that one
shouldn't limit himself to one platform ( be it windows, linux, macOS, etc )

New comers should be able to ask a question, and get something constructive instead of this
bickering, so for my part I apologize for the drama, now can we please move on?

EDIT:
I don't see anything wrong with that man.

Is your desire to learn C++? Otherwise, I would suggest that there are great mud engines written in easier languages that are also cross-platform (win-win).

Yes and No. I took a C++ course this past semester and I have been working almost daily with c++ code since January. So I am learning C++ outside of our MU* world.

However when it comes to hobby time, I like the idea of working with a c++ codebase as it helps to reinforce what I have already learned. I have found more than I can currently understand just in the TinyMud and SimpleMud code.



I have tried Dead Souls and CoffeeMud. I really liked dead souls but there is so much I found it difficult to examine and study the basic engine if you will. CoffeeMud is the same way, and while I love the web interface for building, I am just trying to find something simple to test and build on. Once I understand the individual files and how they come together in the main.cpp file to make said game, I could then move on to something with more existing features. All the extras just confuse me at this point.

I suppose my other option is to find some c++ chat server tutuorials and start there. I just thought I would check with the Higher Powers first.

I actually have some of the same difficulties with Dead Souls. Part of the problem is that an LpMUD is actually two almost totally seperate pieces of software. The driver (FluffOS) implements a sandbox/virtual machine system which accepts sockets, collects input from them, sends output to them, and manages set of "program objects" in the sandbox. The mudlib (Dead Souls) implements all the game logic and actually implements everything you see. The two communicate via a well-defined set of API's, with callbacks from driver events (such as input arriving on a socket), and services the driver provides (such as pre-defined functions you can call from inside the sandbox).

If you want to know how it all works at the nuts-and-bolts level, it takes a LOT of time and study to work it all out.

On the other hand, you don't usually NEED to know much about the driver to build a game using it. You need to know even less about it if you're using a rich mudlib like Dead Souls, since most of the basics are done for you. Even if you dislike how things work, they serve as examples of one way to do it.

But either way, there is a LOT of documentation you have to read to know what's going on. Fortunately, it actually exists.

As far as C++ goes… it really depends on how much of a "game" you want. There are several chat servers, and a C++ version of socket mud I think, that would give you some barebones networking and command parsing. The RaM project was the start of a rewrite of the ROM Diku-codebase in C++, and there's also Merc++ along the same lines. AFKMUD is in C++ and is much further along, although it has some bugs that might be challenging.

However, I don't know if any of those are likely to work in Windows, as they all started out in unix of one form or another.

FWIW, I started out the same way you are. I wanted to have a working game, but I also always wanted
to knuckle down and learn C. Now that thats out of the way a difficulty I've had is focusing so much
on the programming and design that I have neglected the game itself. If I could do it over again, I
would probably be writing all the game data on the side. And I don't necessarily mean building, but
just creating my virtual outline. This way, you have all your logic predefined, and as soon as you
come across something special your project would need to implement, you will be creating a solution
to a real problem.

The reason theres been several posts about using other languages is because C++ is probably not the
best language to create a brand new project in. It can however make existing C bases more manageable
and fun to add complex features.

Thanks for the replies everyone, and thank you JohnnyStar for the much appreciated advice.



What then would be a better language to create a new project in? One of the Script languages like Ruby?



There are easier languages than C++??? I am decent at VB but I am guessing you ment something else?

I am not opposed to learning another language that is better for MUD construction, however I am moving far off course from where I started in this thread. Even after getting the basics of another language, I will still be looking for a bare-bones codebase to start from.

The further I get into this, the more I feel like embracing the hospitality of Dead Souls as it seems to be my only good option. Not that it's a bad thing, I just feel like I am cheating myself by not understanding how it works at the Nuts and Bolts level.

Perhaps I have misled myself into feeling like I need to strip all the parts off this car down to the frame, then start adding all the pieces back in. I guess some soul searching is needed on my part.

I want to eventually become a programmer IRL and I originally thought that by using similar code in my hobbies as well as my studies, the two would complement one another.

Use a language that will add to your toolkit if you're actually looking to make a career out of it some day.

With that in mind I'll give you some advice I normally wouldn't for a mud. I'd go for a C++ mud perhaps in your case. Especially if you need to learn the language. You can always learn multiple languages later on (and you will if you go down that path) but I think it's certainly wise to start your education with something pretty widely universally useful professionally like C++.


Oh, and there's nothing wrong with dynamic so-called "script" languages. They're actually very fit for a lot of projects (such as muds.)

I agree with Runter on this one. Once you get the core concepts down like Object Oriented design, learning
languages like Ruby and Python will come easily. If you were planning on just mud programming I would go with Ruby.
It is a fine language to learn OOP, and has a much shorter learning curve. Whats cool is that a lot of the mainstream
languages used in the business world such as Java and C# have been inspired by C++. If you get into web design your
employer may want you to use Ruby on Rails, so you never know.

I have a Dead Souls project, a C++ project and a Ruby project. No I don't have tons of free time, I just have more fun
learning languages than I do finishing projects. I'm sure one day I'll knuckle down and focus on just one of them, but I've
been able to use what I learn from each project in the others.

Just remember to have fun while you do it, and who cares what other people think. :biggrin:

In my experience, if you want a MUD where the actual MUD Logic is incredibly straightforward, you cannot possibly go wrong with a diku-derivative like Murk++ for instance. It's written in C++ but it is extraordinarily elementary, and you can understand how the mud "works" within a week. The source code is like reading Dr. Seuss compared to the War and Peace of many other games.

Why is that?
Diku hard-coded everything into it, and implemented "scripting" almost as an afterthought. A lot of the ideas are old b/c of old memory constraints, etc. but they are all the more elementary for it.
For instance, "sneak" is implemented like this: When this person leaves this room, if they are sneaking, don't tell people they are leaving.
In another codebase if might be: Toss off the leaving room event, see if if the character has a skill that listens for that event, let that skill override the normal room-leaving logic.

Notice how the second method has more flexibility once the codebase is written, but is far more complex (many more steps)

Now, this surprises me:



Haha. You have not coded a lot huh? C++ is a strongly-typed professional language meant for large compiled programs, designed for speed and maximum flexibility. It's a BIG language with maximum power, and for that it is quite low-level compared to other languages.

You can pick up Python in an afternoon. Everything in C++ is harder – Strings, Arrays, Hash-libs, Persistence, and Networking are all far more difficult.

Take a string in Python. You can regex it, you can literally just add a variable into it (i.e. "Hello there " + character_name),

Python's also weakly typed (no variable type declarations), has almost no formatting ( no {}, and few ()'s, it uses tab level to establish scope ), and doesn't require, for instance, make-files – oh and it's interpreted.

Final aside… why is hashing important? The slowest part of muds is cycling through massive arrays of data – no language, no matter how fast, does that quickly. Python implements a native hash-like object called a "dictionary" which operates like a "map" and associates a string to a value, no hassle.

So… yeah.

I'm not entirely sure why you're saying that C++ is a "professional" language implying that languages like Python aren't. Many companies use Python quite seriously. Generally I agree with the things you said, or perhaps at least the sentiments, but many details are off. For example, C++ strings can ne added together.

Professional as I rather sloppily stated it == Standard is no longer evolving at the rate of, say, Python which has 3 different professional versions in general production use (2.5, 2.6 and 3.x) one of which really isn't back-compatible with the others.