17 Feb, 2009, JohnnyStarr wrote in the 1st comment:
Votes: 0
Ok, just thought i would throw this out there.
~
I have spent the last 6 months learning C. And I am torn because i do love the simplicity of the language.
I love the fact that it's open source and that it runs on Linux/Unix. I love GDB and i love GCC.
I even love juggling pointers, it makes me feel powerful!

But when it comes to having to write / maintain low level functionality, it can be kind of daunting.
Some of you have been super helpful in your replies to some of my other posts about MySQL.

Anyone who's read them may have noticed that i'm more obsessed with coding than mudding. I guess its
just the way i am.

I love the idea of being able to easily change things in my MUD. And find that due to all the low level memory
issues, this can be not as fun as say, C# or JAVA or even Ruby due to the high level garbage collection.

Any Thoughts?
17 Feb, 2009, David Haley wrote in the 2nd comment:
Votes: 0
The real question to ask here is: what are you trying to achieve?

If you just want to mess around with code, and don't really care about having a fully operational MUD, sure, start from scratch if that floats your boat. But know that you will not have an operational codebase anytime soon, and also know that you are basically throwing away a whole bunch of game logic that you will need to recreate one way or another.

If you want to open a MUD "soonish", you probably don't want to start from scratch. But if you do want to play with higher-level languages, nothing stops you from embedding such an interpreter into your C program. In fact, a lot of people are doing that these days, with Lua, Python, Ruby…

So I guess the best way to answer this question is to first figure out what you're trying to get out of all of this. If you don't really care about having a fully functional game world, I'd write it from scratch – you'll probably learn more that way, but you'll also make more mistakes along the way (such is the nature of things, and it's the best way to learn). Just keep in mind that you won't have a functional codebase anytime soon.
17 Feb, 2009, Scandum wrote in the 3rd comment:
Votes: 0
staryavsky said:
I love the idea of being able to easily change things in my MUD. And find that due to all the low level memory
issues, this can be not as fun as say, C# or JAVA or even Ruby due to the high level garbage collection.

Any Thoughts?

C is as easy or difficult as you make it, though it can be a lot of initial work to write your own garbage collection and memory handling routines.
17 Feb, 2009, David Haley wrote in the 4th comment:
Votes: 0
I'd disagree with that – some things are simply more easily done in languages other than C – especially in C rather than C++, where operator overloading can make some magic happen under the scenes. For instance, yes, you can make smart string objects in C, but you'd have to only manipulate them with special functions. Higher-level languages can make that go away.

But yes, it is possible to make C easier to work with. I just don't agree that you can make it as easy as higher-level languages.
17 Feb, 2009, quixadhal wrote in the 5th comment:
Votes: 0
You can make C less painful to work with, but it's not designed to be easy. It's designed to allow you to write high level code while still being able to get to the bare metal if you need to.

For example, one of the reasons I really like using perl (and lately, ruby) is that it merges the ability to match strings against regular expressions seamlessly. You can, of course, use the pcre library in C to get the same functionality, but not simply. No matter how many libraries you weld on, strings are not a base type in C, and anything you do with them involves bundling them up into functions and passing them around.

#include <stdio.h>
#include <string.h>
#include <pcre.h>

#define OVECCOUNT 30 /* should be a multiple of 3 */

int main() {
const char *error;
int erroffset;
pcre *re;
int rc;
int i;
char str[] = "regular expressions=very cool"; /* String to match */
int ovector[OVECCOUNT];

re = pcre_compile (
"([^=]*)=(.*)", /* the pattern */
0, /* default options */
&error, /* for error message */
&erroffset, /* for error offset */
0); /* use default character tables */

if (!re) {
printf("pcre_compile failed (offset: %d), %s\n", erroffset, error);
return -1;
}

rc = pcre_exec (
re, /* the compiled pattern */
0, /* no extra data - pattern was not studied */
str, /* the string to match */
strlen(str), /* the length of the string */
0, /* start at offset 0 in the subject */
0, /* default options */
ovector, /* output vector for substring information */
OVECCOUNT); /* number of elements in the output vector */

if (rc < 0) {
switch (rc) {
case PCRE_ERROR_NOMATCH:
printf("String didn't match");
break;

default:
printf("Error while matching: %d\n", rc);
break;
}
free(re);
return -1;
}

for (i = 0; i < rc; i++) {
printf("%2d: %.*s\n", i, ovector[2*i+1] - ovector[2*i], str + ovector[2*i]);
}
}


vs.

my $str = 'regular expressions=very cool';
$str =~ /([^=]*)=(.*)/;
my ($key, $value) = ($1, $2);
if( defined $key ) {
printf("%s = %s\n", $key, $value);
} else {
print "String didn't match\n";
}


Of course, the example is contrived to show my point. Yet, notice how the vast majority of the C code is setup and teardown work. High level languages tend to hide most of that setup work so you don't have to waste so much time writing stuff you've already written thousands of times before.

It should be noted that if you tried to use an invalid regular expression in the perl snippet, it would throw a warning and continue executing (into the no match code). If you wanted to check for that, you'd have to put it inside an eval block, but I'm too lazy to bother.
18 Feb, 2009, elanthis wrote in the 6th comment:
Votes: 0
Thank god for C++. You can keep all of your existing C code and add a handful of light-weight interfaces that you really need, e.g. a real string type. The STL even provides a std::string that does about 80% of what you'd want out of a high-level string facility, and the other 20% can be implemented to have a very easy-to-use interface.

The default C++/STL library is pretty anemic, but nothing stops you from mending that by using additional libraries or (for your own edutainment) coding your own. Just avoid going overboard – C++ is not Java, and if you really want to objectify everything and build your whole app like that, you mightn't use C++.

Memory management appears to be your biggest beef with C, and you'll be glad to know that C++ can (but doesn't automatically) solve that. Use std::vector instead of manually-allocated dynamic arrays, use std::string instead of char*, and use tr1::shared_ptr<> typedefs instead of raw pointers to your structs. There is a little more to it than that (e.g., understanding when to use weak pointers if you're using something like shared_ptr), but that'll cover most of your bases.

So no, there's no need to totally rewrite your code. I wouldn't deter you from doing so, but really think about whether you want to reimplement _everything_ you have already. Ruby or Python or whatever may be way easier and quicker to code in, but it can still take an awfully long time, especially if you're learning the language along the way. You really shouldn't try to code a large and complex application like a MUD as your first foray into a new language, either.
18 Feb, 2009, Idealiad wrote in the 7th comment:
Votes: 0
DavidHaley said:
If you want to open a MUD "soonish", you probably don't want to start from scratch. But if you do want to play with higher-level languages, nothing stops you from embedding such an interpreter into your C program. In fact, a lot of people are doing that these days, with Lua, Python, Ruby…


With NakedMUD being a nice example of a C/Python server that's readily available.
18 Feb, 2009, quixadhal wrote in the 8th comment:
Votes: 0
I should also point out, as others have too, that it makes a big difference WHY you're writing the code in the first place. If you have a production MUD already, you probably have to stick with what it uses, or slowly migrate your way into something else on a test server. C -> C++ is possible, but tedius. C -> ruby or python… you'd probably have an easier time building up from scratch so you don't write "bad" ruby code because of the way the C code worked.

If you're designing a MUD and your goal is to make it very mutable at run-time, but not have to build the entire infrastructure yourself, I point at the LP MUD people. LP's are fantastically flexible, and can be very robust. You do have to learn BOTH the LPC language AND how the particular mudlib you're starting from work, and that can be a big downside.

If you really want to write it all yourself, you can choose to use a system like an LP MUD, but write your own mudlib. That nets you the benefits of a mutable run-time system and not having to deal with low-level socket/memory management/etc…. but it's almost as much work (maybe more) as writing totally from scratch. And you still have to learn how the LPC language and driver interact.

There are a lot of already existing projects that will help you avoid starting from the very ground floor. SocketMUD for C, RocketMUD for ruby (or TeensyMUD, if you want a bit more already there), NakedMUD if you want your content in Python but to still have a C core. You can go the other extreme and choose one like Cold, which is a persistent object store you can write a game around.

I would probably say, if you have a language of choice, use that and try to find something barebones to build from. If you don't, try a few and see if one clicks. If you like the way python code looks, learn python. If you like C, C++ or LPC are both good choices, depending on how far down you want to get.

FWIW, I wrote C code for a good 15 years before being seduced by Perl. After 5 years of that, I cringe at all the "busy work" I have to do to get anything accomplished in C. *shrug* I'll tell you one thing, do what's fun, because unless somebody's paying you, you want to enjoy as much of it as you can. :)
18 Feb, 2009, Tyche wrote in the 9th comment:
Votes: 0
You might want to delve into machine code as nothing satisfies a craving for power better than directly manipulating the registers on your machine and seeing it dance to your every whim.
18 Feb, 2009, Cratylus wrote in the 10th comment:
Votes: 0
quixadhal said:
I'll tell you one thing, do what's fun, because unless somebody's paying you, you want to enjoy as much of it as you can.


:)

People who sweat and bleed and exert themselves for "the community" are doing
no favors to anyone. They wind up bitter and vindictive and a negative influence.

People who sweat and bleed and exert themselves because they *want* to, for their
*own* entertainment, those are the gods.

-Crat
http://lpmuds.net
18 Feb, 2009, quixadhal wrote in the 11th comment:
Votes: 0
Tyche said:
You might want to delve into machine code as nothing satisfies a craving for power better than directly manipulating the registers on your machine and seeing it dance to your every whim.


HAHAHA:
LDX #$0F
STX $D021
DEX
BNE HAHAHA
18 Feb, 2009, Scandum wrote in the 12th comment:
Votes: 0
Cratylus said:
People who sweat and bleed and exert themselves for "the community" are doing
no favors to anyone. They wind up bitter and vindictive and a negative influence.

Your post is worthless without at least 3 examples (user names) of each kind.
18 Feb, 2009, David Haley wrote in the 13th comment:
Votes: 0
Idealiad said:
With NakedMUD being a nice example of a C/Python server that's readily available.

My understanding (based on the information on the website) is that NakedMUD does not implement a game, but rather a framework that is less bare-bones than, say, SocketMUD. So while yes, it's a good example of something to get started with, I wouldn't consider it to be something to pick if the idea is to have a whole game ready and waiting for people to play.

elanthis said:
You really shouldn't try to code a large and complex application like a MUD as your first foray into a new language, either.

Or if you do, be prepared to make lots of mistakes and be willing to throw things away as you learn from your errors. I happen to think it's not really a bad way to really learn things, but it requires some amount of patience. Still, I'm assuming at least a basic understanding of the language – "foray" being defined as the first project rather than messing around with hello worlds and similar tutorials. If you have truly never used the language before, I'd completely agree with elanthis.
18 Feb, 2009, elanthis wrote in the 14th comment:
Votes: 0
quixadhal said:
C -> C++ is possible, but tedius.


If you're converting the code from "good C code" to "university-quality over-objectified C++ code" then yes. If you're just coding C using a handful of the more applicable C++ facilities, there really isn't any conversion to speak off. Just start using C++ features where you feel they'll be most useful, or rewrite any particularly painful bits of C code.

A lot of purists call such applications "monstrous hybrids" but in reality the whole _point_ of C++ is that you can use just the bits you need mixed in with existing C code. If you wanted to "convert" the app to a new language, C++ is probably not the language to convert to. Java or C# might be better bets if you want C-like syntax but with a total conversion to an OOP framework. C++ is for when you need some OOP in places, some functional programming in places, some procedural programming in other places, and want to keep compatibility with existing C code or get good low-level control and performance.
18 Feb, 2009, David Haley wrote in the 15th comment:
Votes: 0
Fully agreed. There's really no point in converting everything if you're just going to add dummy getters/setters for everything instead of having member fields. It's much more productive to convert things as you have reason to. For instance, if a character's short name might change depending on context, it might make sense to hide the short name field, and add a method getShortName() that does the right thing.

Don't refactor code just for the sake of it. Refactor when you have something to gain from it.

Having access to the STL on occasion is immensely helpful, far more so than having objects that are just thin wrappers over their data fields.
18 Feb, 2009, cbunting wrote in the 16th comment:
Votes: 0
Hello,

If you are mainly interested in the learning aspect, you may want to check out sourceforge.net, and various other open source hosting sites.. There are already ton's of from scratch mud servers, mmorpg servers and whatever else you are looking to learn..

There are a lot of places to start looking.
Chris
18 Feb, 2009, JohnnyStarr wrote in the 17th comment:
Votes: 0
Wow!

Once again thanks for the info guys.

Hate to admit it, but i know very little about C++ and if i have the
ability to add something like that, it sounds like its worth looking into.

I really wouldnt want to start from scratch unless i was able to rationalize the
many hours it would take. Whether that was worth not just redoing some coding
on an existing codebase. This way if i learn more about C++ i can keep what i have
and take advantage of some of the perks.

Ruby sounds cool, i might start my own codebase from scratch for learning purposes. But here's one last thought, i've heard ruby is slower. Which makes sense because its written in C. Would speed matter on new machines?
Considering that when DIKU / MERC was written years ago and memory and CPU
speed was a hudge deal???
18 Feb, 2009, David Haley wrote in the 18th comment:
Votes: 0
It is rather likely that speed won't matter for your purposes, unless you're doing something very inefficient. Indeed, resources are far more available today than they were back in the early days of MUDding.

BTW, Ruby is slower not because it's written in C (did you mean to say that?) but because it is an interpreted language with all kinds of extra things going on, with nearly every line of code corresponding to many things happening behind the scenes, unlike C which tends to be "what you see is what happens".
19 Feb, 2009, JohnnyStarr wrote in the 19th comment:
Votes: 0
Oh ok, that makes sense.

Thats what i was getting at. Not saying that because it's written in C alone. My point
was that it's logical for ruby to be slower than C due to the fact that C alone
is what you see is what you get, just like you stated, and that ruby must have more layers
of code, because anything you write is 'interpreted'.
19 Feb, 2009, Davion wrote in the 20th comment:
Votes: 0
staryavsky said:
… and that ruby must have more layers
of code, because anything you write is 'interpreted'.


I know some interpreted languages (like python for eg.) can be compiled to kinda lose this interpreted stigma
0.0/28