I'm utterly new to coding and designing a mud, so I have a few questions which I hope aren't too annoying.
First, one of the races I want to have would devour souls. The way I had thought to do was would be to have each mkill of a mob without a certain level range (5 below and 5 above, so that a player at level 16 would have a range of 11-21) would add one to a value in the player's pfile, aptly called 'souls'. Then, at some later date, the player would be able to go to a certain room, and decrease that soul number to get certain items.
Sort of a cross between mkills and bless, I suppose, but I have no idea how I would actually do it.
Secondly, I had a skill in mind that, when used, would have one, random effect from a list. For example, you'd use the skill, then the actual attack would do a kick, or a punch, or a headbutt, etc, randomly. Is it possible to do that? I'm not sure how attacks are coded in, or if you can do a random effect from a list or not.
Thirdly, is there a way to cause damage if certain races use certain skills? For example, I was gonna have a race that would be damaged if it used a portal opened by someone else (or by themselves, really just portals in general).
And lastly, and this is more of a "will this work" sort of thing, but could I have a system where all the attacks for various classes are in the racial list, and then the different classes actually practice the skills in class-specific rooms? This would be for a class-changing system, so that you could change classes and keep the skills, but only learn the skills if you're actually in that class.
Sorry, but I'm really new to this and I have no idea how a lot of this stuff works. I'm not asking for people to do it for me, but a good idea of what to do and where would be extremely helpful. Thanks.
My first thought is that "anything is possible" when programming, my second is that doing complex changes like that when "I'm utterly new to coding and designing a mud" is probably going about things the wrong way.
A lot of the stuff in SMAUG is hard-coded in a rather annoying way, so that you can hunt around a fair bit in the code to make it behave in a different way to the way the original coders wanted. Sure, it can be done, but I would start with a simple change, like maybe your portal idea. You would need to find where, in the code, it opens portals, find out what race is doing it, and then start to make your changes.
The MUD is such a large and complex program - even without making changes - that you are well advised to come to grips with how it currently works. Then start making small changes, and work your way up to bigger ones.
One thing you need to look at, if you want to change what is saved to the player pfile, is both the saving and loading code, plus having somewhere in the player's data structure to store the value. Then you need to make sure for a new player that this is initialised (eg. to zero).
Thanks. Would you mind directing me to which file does that whole saving/loading thing with pfiles? I've tried looking through them, but a lot of them seemed named weird things and a lot of the language inside is confusing.
My approach in a situation like this is to find something I know is already in the player save file, like "pkills" and scan for that word.
As Conner points out, save.c is the appropriate file, and I have to say I think it is a pretty descriptive name too. :P
Scanning through save.c for "pkills" you find a couple of spots it is mentioned (one where the number is loaded, and one where it is saved). Thus, putting similar code for "souls" in a similar place could be the way to go.
Quote:
... a lot of the language inside is confusing ...
I am troubled by the thought of changing a MUD server being your first C programming experience. I strongly advise you to become more familiar with C by doing some simpler examples. There are some subtleties to running servers, like the asynchronous nature of communications (for example, trying to build in pauses is not simple), plus the heavy use of pointers.
If you've never seen code before, there are lots of tutorials and introductions on the web. I agree with all the recommendations Nick gives you. It will be more fruitful in the long run, far less frustrating and far more valuable to you, to take some time off now and learn to walk before running a marathon. I would start with a simple "hello, world" program; move up from there.
Another reason to start slow is that diving in too quickly will give you some very bad habits, because you will develop a "hackish" style where you stop when it appears to work, but without truly understanding what happened where and why. This only leads to trouble later on. If you're in college, take an intro CS class. If you're not, look around on the web for tutorials. There is lots of material out there; you'll just have to take the time and patience to walk through it.
But of course, we are here to help you as you learn, so feel free to ask questions.
Thanks, I'll be sure to study some tutorials on the basics. I'll have to check to see if my campus offers an intro CS class, but that would definately help me out a lot.
You know, Nick, for what consolation there might be in this for firedraconian and others, Smaug was my first experience with C programming a little over 3 years ago, but I bought a few good books on C and got some great help from members of our community (too numerous to mention) and have learned an amazing amount.. and frankly, if I do say so myself, have developed a pretty nice mud out of it.
So it can be done, but I will give Nick's argument some credence too. This was not my first programming experience, I'd already run an ISP for 8 years on my own, and was certified A+, Network+, MCSE+I, and had previously learned and used cobol, fortran, pascal, basic, and a few other languages, so I wasn't totally new to programming, just to C based programming, and I am still learning.
I also wouldn't recommend starting out trying to change such major features, rather I would strong agree with Nick that you're better off starting out small/easy and building up.
If you are a strong programmer already, being new to C is almost irrelevant. If you are completely unfamiliar with references, memory, functions, loops, control flow etc., that is the problem. A language is (usually) just a question of syntax, not concepts. (Mastering the language, however, might require mastering the concepts.)
Again, for what it's worth, I was not a strong programmer, I had a little background in a variety of languages, but had avoided programming any time that I possibly could for many professional years. I did not have a good grasp of most of those concepts either. By far, the marojity of what I know at this point is, frighteningly enough, gleaned from the last three years of playing with Smaug's code.. and a great many kudos to those who's struggled along to help me figure out how to do the things I'd tried along the way, and to those who've fixed my mistakes and were patient enough to show me what I'd done wrong and how to do it right instead.
What I meant is that even some basic exposure can get you a really long way. Basic exposure can be as simple as understanding elementary control flow, function calls, very basic data structures, and such things. The difference between somebody who has had such exposure and somebody who is truly completely new is pretty amazing.
That being said, it's quite possible to have Smaug as first exposure, it's just that the novice has to accept that they won't be changing the face of the world for quite a while as they learn the ropes. If they start small, then by using good community resources they will get very far, much further than if they try from the get-go to make very complicated changes.
Now there, I fully agree. From my own experience your best best is to make yourself a todo list, in fact, make it a help entry in help.are so even your players can see what you intend, and put on it all your great worldchanging ideas, and even a few of the really minor ones. Then start with the smallest things that are going to be easiest and try to do them. Once you get those right, move up to the next smallest changes until after a couple of years you're actually ready to tackle the really tough things.. by then, you may even find that you've got some other great ideas too, or that your players have some for you. Lord knows that my players never seem to run short of ideas for me... *LOL*