Hey there. I'm going to put on my newbie hat for a while, so if you get mad at lazy newbies, this is a swell time to go take a walk, read a book, or chat with old friends.
I'd like to get a better sense of the game "feel" for Diku derivatives. The obvious way to do this is to just play dikus, "duh".
However, I remember what it was like to play any kind of mud at first. It took a long time to figure things out…and in the end, my point isn't spending time on dikus to have fun, so much as understanding what commands people are used to, what play they engage in, etc, without investing the hours/days/weeks in becoming proficient.
The idea is that I'd like to develop a Diku emulation mode for my lib, and want to know if that's a reasonable goal given my limited time.
I did try to install a coupla diku deriv codebases, but my computers are not "mainstream", and I'm not a C guy, so investing the time plunging through my computer's allergies to foreign code is again, discouraging.
I really would like to get a sense for "typcial" (as opposed to my newbish) Diku play, but given my priorities and limitations, it looks like it'll have to put it on the backburner.
Unless one of youse helps me out with a super-simple request.
If you *play* on Dikus, please enable logging on your client, and play a typical session (minus the ts and personal stuff, of course). When you're done, please make sure the log is clean of data that you don't want to share… then share that log with me.
I want to follow an experienced player do the normal Dikushy things they do, and see how typical "good" (not stock) muds behave in return.
You can send me a personal message here letting me know where to get it, or you could email me. My name is cratylus and I have an email account witht he domain name of comcast.net
I'd very much appreciate the information…and my apologies if my sloth in this matter seems excessive!
Not an issue, and I wouldn't call it slothful it's not asking for any more work for us really, just to log a typical session (with my client's 100,000 line scrollback I don't even need to make a traditional log…
I'd be more than happy to help out, but I don't put in much if any playing time anymore and wouldn't make a very good candidate for a proper session log.
From a user perspective though I honestly don't think that there would be that big of a difference noticed.
You know, black background, colored text.. get the diku room format going and the general diku command set.. maybe a diku-ish prompt line and diku tokens for color codes, who'd know the difference. :wink: :lol:
Oh, very important, don't forget to make the players have to eat/drink every few minutes too. :wink:
Mine came down the Diku/Merc/Rom line as well, one of the best changes I ever made was to the hunger/thirst etc code. I still have eating and drinking, but it's about 1/10th as often, based off your body size, activity etc.
[tangent]One thing, I'm looking for perks to eating 'good' food (so that cooking good food has a purpose other than some random crafting thing). One thought is a kind of happiness (perhaps you heal slightly better if you eat good food etc). I don't want munchkin '+3 strength for 3 ticks' kind of bs, just something that makes eating good stuff somehow worthwhile. Thoughts? [/tangent]
Skol, I'd be happy to share my food system with you. It's just what you're looking for, though it is a bit complicated. Basically, there are three food groups and each race needs to eat a different balance of each. Each food contains differing amounts of each group. A balanced diet affects regen, one food group affects hp, another mana, the other moves. This does mean you have to go through all the food in your game and change the values, however.
Hey Sandi, if you're willing to submit that food system to the repository here, that sounds pretty cool. (Though I'd prolly mutilate it slightly to add extra 'food' groups for special races…) :wink:
It's generally held there are 4 or 5 food groups, but I condensed them to three as there are only five values on a Merc/ROM object. One's used for "poison", and another is the timer. My food goes bad after a while, so I needed those. :)
Well, I wasn't thinking in terms of human divisions of food groups per se, I was thinking that some races (like dragons or illithids, for example) might eat things that other races wouldn't consider food.
There's only 5 values in most smaug muds as well, but it's not really all that hard to expand the number of values, AFKMud has 10 or 11 I beleive, as does my own derivative. I think mine has 11.
Rom as 0-4, but I've considered expanding those on occasion ;)
Thanks for the offer Sandi! What I'm thinking of will probably end up more simple than that, purely so that the act of eating doesn't become a pain in the ascii. Basically a quality value, 1-100 for simplicity, then the hunger/fullness/poisoned etc, although I'm considering changing poison to types of poison etc, but that's another tangent. The idea is that then food is created from say caught fish (based on fish value, price per pound etc, then skill in preparing and cooking), or butchered animals (the usual steak, ribs etc, same checks on preparing and cooking). Herbs/Spices will add to the foods quality etc, up to say 5% increase in quality. Which spices depend then on which types of food. Gathering herbs, herb lore to dry them (preserve etc), then spice lore to combine them into specific spices etc.
Basically it's the start of my crafting system, but the player value will be increased mood (helping increase healing rates, fighting ability, defense, haggling etc), albeit a small increase.
Of course some will be sold in shops (both foods and spices/herbs etc), but at a much higher cost, with more mundane results.
Thanks much for delving off into that tangent with me, sometimes it's tough to find people to hash over conceptual directions.
You know Skol, in Smaug the way this sort of thing is handled is that objects have values called v0, v1, v2, v3, v4, & v5 (as Kayle pointed out earlier), and each of those values (purely int values) takes on a different meaning depending on the object's type. In the case of an object type food, v0 is used to determine the food value (how filling it is, or more precisely, how much the character's "hunger" is increased (sated) by eating that object), v1 is used to determine the condition of that object (is it raw, partialy cooked, properly cooked, overcooked, burned, spoiled, etc?), v2 is not currently used (easy spot to add your quality factor), v3 is a binary toggle for setting the item as poisoned or not, and v4 & v5 are also unused. Since I'm not really familiar with ROM, I don't know how it handles object values or if it has them at all, but if it does, this would be the easiest way to add what you're talking about. In fact, now that I think about it, it might be the easiest way for me to handle what I want as well. If ROM doesn't already support this sort of object values, perhaps adding something like it would be the way for you to go?
ROM does have the same values, though one less. V1 is the 'nutrition' value. That is, you can fill yourself on V0, and still be hungry. :)
I made V0 be "bulk", so it has a similar use, V1 is "protein", and V2 is "carbs" (or more often, sugar). V4 is a timer that gets decremented in the way lights do, and when it hits 0 the 'eat' command responds in several ways, depending on which of the first three values is greater. Spoiled protein poisons, spoiled carbs make you barf (you lose about 3/4 of what you have eaten), and bulk that's past date is as hard as a rock (no longer food).
Each pfile tracks the three values, and the code that decrements the values on a tick is randomized, and also modified by position. Also, each race array in const.c contains modifiers so some races metabolise food types faster than others. A Faerie will crave sweets, while a Dragon will want mostly meat.
The real gimmick is, there's a rather complex averaging system that only shows the player one value for 'hunger'. So, they know they need to eat, but eating the right thing requires careful observation. When a player eats a food that contains more of what they are most hungry for, they see the message "That hit the spot!" to guide them in their culinary choices. :)
I also carried the system over to the liquid table, so mead is sweet and milk has protein.
get mad at lazy newbies, this is a swell time to go take a walk, read
a book, or chat with old friends.
I'd like to get a better sense of the game "feel" for Diku derivatives. The
obvious way to do this is to just play dikus, "duh".
However, I remember what it was like to play any kind of mud at first.
It took a long time to figure things out…and in the end, my point isn't
spending time on dikus to have fun, so much as understanding what
commands people are used to, what play they engage in, etc, without
investing the hours/days/weeks in becoming proficient.
The idea is that I'd like to develop a Diku emulation mode for my lib,
and want to know if that's a reasonable goal given my limited time.
I did try to install a coupla diku deriv codebases, but my computers
are not "mainstream", and I'm not a C guy, so investing the time plunging
through my computer's allergies to foreign code is again, discouraging.
I really would like to get a sense for "typcial" (as opposed to my newbish)
Diku play, but given my priorities and limitations, it looks like it'll have to
put it on the backburner.
Unless one of youse helps me out with a super-simple request.
If you *play* on Dikus, please enable logging on your client, and play a
typical session (minus the ts and personal stuff, of course). When you're
done, please make sure the log is clean of data that you don't want to share…
then share that log with me.
I want to follow an experienced player do the normal Dikushy things they
do, and see how typical "good" (not stock) muds behave in return.
You can send me a personal message here letting me know where to
get it, or you could email me. My name is cratylus and I have an email
account witht he domain name of comcast.net
I'd very much appreciate the information…and my apologies if my
sloth in this matter seems excessive!
Thanks.
-Crat
http://lpmuds.net