Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > Advanced MUD Concepts
Click here to Register

Reply
 
Thread Tools
Old 07-13-2002, 12:58 PM   #1
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 849
Jazuela will become famous soon enoughJazuela will become famous soon enough
Jazuela is offline   Reply With Quote
Old 07-13-2002, 01:29 PM   #2
tresspassor
Member
 
Join Date: Jun 2002
Location: Minneapolis
Posts: 45
tresspassor is on a distinguished road
tresspassor is offline   Reply With Quote
Old 07-13-2002, 02:48 PM   #3
Dulan
Senior Member
 
Join Date: Apr 2002
Posts: 354
Dulan is on a distinguished road
Send a message via ICQ to Dulan
I normally keep out of these discussions. Unless outright false information has been posted.

This is wrong. Outright wrong. Let's assume an average of 6 characers per player name. * 1,000. That is 6k - 12k if you decide to store the player name and the given player name. An average-size pfile on most derivitives is around 20-30k. Learn some basic math before you make those sorts of comments. The additional pfile space is NOTHING for a MUD with "hundreds of thousands of players".

Another uninformed and incorrect statement. It is exceedingly easy to add new variables to pfiles in most commonly-used languages for MUDs (Most, not all.) All the programmer has to do is have the initial variable for, say, hair not have a '0' value at all. Then, if the player has a '0' value, have them go through character generation.

The rest of your post is full of similar holes, but I've got to meet some people to fix some issues in source code, thus, I'm out. I'll let someone else pick apart the rest of your statements.

-D
Dulan is offline   Reply With Quote
Old 07-13-2002, 03:10 PM   #4
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

I'll leave the dynamic descriptions and such alone, but I do believe that introduction systems could be done much better (also eliminating some of the drawbacks) if we change our perception of a character's "memory" of introductions.

Most of the introduction systems I've seen allow you to introduce yourself to a player, and then forever will you be identified to that player. What I propose is a memory system: You will introduce yourself, and then the player who you've introduced yourself to will add a memory structure along with a memory value. If you do things such as fight with the character, talk to him often, buy things from his store, etc., this value would increase. The value should gradually decrease, so that the player forgets people he's been introduced to if he never interacts with them. This would mitigate some of the storage problems, but also introduce new ones because of the extra space required to hold the aforementioned value.
Yui Unifex is offline   Reply With Quote
Old 07-13-2002, 05:21 PM   #5
tresspassor
Member
 
Join Date: Jun 2002
Location: Minneapolis
Posts: 45
tresspassor is on a distinguished road
It'd be interesting if they went off say, intelligence, so Player X can remember 50 players's names, but player Y could only remember 3

And the duration of "forgetting" players would be based on that person's intelligence

It may add different issues, the codebase i'm used to must be pretty different from what everyone else is famalier with.

So with the knowledge of what I'm used to it would add more processing, mainly because you'd constantly be looping through a vector filled with 100's of values, and if there is 20 players in the room that's 20 calls to the same function.

There'd be some more processing in determining if the person has "forgotten" but that could all be related towards a time-stamp that is created during the "greeting" or "fighting" times, to save ticks when looping through the vector: (compare names, compare timestamp, ok go).

But all of that can be worked around

interesting idea
tresspassor is offline   Reply With Quote
Old 07-13-2002, 05:28 PM   #6
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 849
Jazuela will become famous soon enoughJazuela will become famous soon enough
Interesting, but you're getting WAY ahead of a very simple question. In the game I'm talking about, no such greeting system exists, and it was *just an example* of different aspects of dynamic code. It wasn't even the thrust of the arguement on the other forum, though that one example was taken out of context and trashed soundly. That's what brought me here with the question.

Not "how can we make greetings work" or "how can we make greetings better." But rather, CAN greetings work in a massively populated game? And it isn't even greetings. It's any sort of dynamics where you are seeing more than a few dozen people in a day's time. We're talking a game with literally, several HUNDRED THOUSAND character pfiles, and usually close to 1500 characters actively in the game *at any given moment.*

Can a database handle the kinds of dynamics I've seen in small population games, if the database is filled with that many pfiles?

That's my question.

Edited to add - I'm not sure it would even make any sense to do greetings in a game like that. You walk into one of the more popular rooms and see:

Room Description.
Also here are an elf, an elf, an elf, a dwarf, a giant, an elf, an elf, a human, a human, a human, an elf, a dwarf, a dwarf, a human, the corpse of a giant, a giant, a giant, a human, a dark elf, a dark elf, a halfing, a halfling, a halfling, a human, and a tiny kitten.

Trying to look at each one of those people before deciding which one to introduce yourself to would be totally nuts, especially when the characters come and go every second and the entire list of "Also here" people change constantly. By the time you get to the 5th elf, he isn't even there anymore.
Jazuela is offline   Reply With Quote
Old 07-13-2002, 06:14 PM   #7
Robbert
Member
 
Join Date: Apr 2002
Location: #### Paso, Tx
Posts: 89
Robbert is on a distinguished road
Send a message via ICQ to Robbert Send a message via AIM to Robbert
The question is not can the database handle it, but are the programmers knowledgeable enough to make it work efficiently.

If they are citing database limitations as a reason to not do it, I doubt the answer is "yes". Databases are, by their very nature, unlimiting. The limiting factors are the ability to efficiently sift through the wide array of data they present.

In a large-scale system such as yours, I would suggest a two-tiered system, along with the bells and whistles mentioned in the in-depth responses, such as ability to forget, limitations based upon intelligence, etc. Keep all known persons in one system (structure, array, binary heap, or whatever is used). Second, maintain a second listing which is referenced first, and tracks the most recently used name(s), up to a degree of N.

There are umpteen schools of thoughts on efficiency, but only one true final exam: if it lags the game, then there's a better way to do it.

Dynamically creating the short description of the person based upon a known control (the viewer) would be much faster in comparison to indexing a list of known individuals and replacing the short desc with their name. "An elf much taller than you, a very short elf, three dragons, two turtles, and a partridge resting on the limb of a pear tree are all here." is, while logistically a nightmare tangle of code, relatively simple cost-wise compared to "Joe the High Elf, Uther the Short (an Elf), Ember the Red Dragon, Crytos (a Dragon), a very large Green Dragon, two turtles, and a bird are here."

KaVir's treatise on dynamically built descriptions was more in line with creating what you see when you look AT a person, rather than returning what is seen in a room. Quzah wrote a method of dealing with this as well. I do not believe either of them dealt with handling a dynamically-built short description, although it could be extrapolated from their work. (I may be wrong, I havent looked at Quzah's Interactive Descriptions or KaVir's method in a few years).

But, to summarize: In answer to the question "Can a database handle large-scale numbers": a resounding YES. Databases were created for that very reason. Note that a database is very different from a data structure.
Robbert is offline   Reply With Quote
Old 07-13-2002, 07:12 PM   #8
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 849
Jazuela will become famous soon enoughJazuela will become famous soon enough
Well lacking a response from KaVir (who is "the dood" as far as what I've read here about dynamic), I think I'm gonna go with Robbert's explanation and answer.

Just so's ya know - it isn't my game (I know you knw that, but other readers might not realize it after reading you refer to it as that). It's GemStoneIII, and there's this arguement on an unofficial game forum about some new changes.

The change now has Joe the The Human (which always existed) changed to Joe the Human, who appears to be from Jantalaar.

My concern when I posted, was how the heck does anyone know *just by looking at someone* where they're from? The brand new documentation on the new "culture" racial things doesn't say that Jantalaars are heavier than other humans, or always have a mole on their nose, or always wear their hair shaved closely to the scalp. There's nothing to differentiate between a Jantalar human and any other type of human.

So I told the readers I thought the change was lame, that it detracts from roleplay, because the twits who "don't get it" now have one more way to "not roleplay" - they don't have to ask "where are you from?" because their computer screen tells them where you're from. It doesn't promote roleplay, it doesn't promote anything, and so I felt it was a waste of the coders' time when they could've been spending their time coding more interesting things. And I mentioned dynamics as an example.

Well the floodgates burst open on that, and no one's interested in even thinking that anything could be better, yet they're also not interested in looking at places I think do it better.

I don't even PLAY games that have dynamic code, because it's my personal preference not to. But I just thought it was danged myopic and narrowminded of them to refuse to entertain the idea that such code *could* be an improvement, and since coders do this sort of thing FREE elsewhere, why can't the coders of this other game even consider it as an option?

::shrugs:: At least now I can refute their claim that it isn't viable. It is, and Robbert says so, and I trust his thoughts on this stuff because he's one of the ones who does it. So there. Nya.

R - who loves being right.
Jazuela is offline   Reply With Quote
Old 07-13-2002, 07:48 PM   #9
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Well I'm afraid I've been out quenching my thirst again, so I'm a little delayed in responding - however it seems to have been summed up pretty well already, so I won't go into great detail. Suffice to say that there are many variations on character recognition, and it is indeed feasable to implement it in a game of the size you specified.

However your problem seems to be more of a "race recognition" than an individual "character recognition". It would be extremely simple (and use hardly any memory) to store which races each character is familiar with.

As Robbert pointed out, most of my discussions and debates have concerned dynamic descriptions rather than character recognition - however I have implemented character recognition in the past, and have also written an article about such a systems (complete with a codebase-independant snippet which provides the basic framework) in issue 3 of the . So I do have some familiarity with the subject at hand.
KaVir is offline   Reply With Quote
Old 07-13-2002, 07:56 PM   #10
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 849
Jazuela will become famous soon enoughJazuela will become famous soon enough
Jazuela is offline   Reply With Quote
Old 07-13-2002, 08:04 PM   #11
KaVir
Legend
 
KaVir's Avatar
 
Join Date: Apr 2002
Name: Richard
Home MUD: God Wars II
Posts: 2,052
KaVir will become famous soon enoughKaVir will become famous soon enough
Okay, well that would require character recognition, as you'd have to store information per character per character.  It's still feasible though, with only a small memory overhead (depending on how it's done, of course).
KaVir is offline   Reply With Quote
Old 07-13-2002, 10:19 PM   #12
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 849
Jazuela will become famous soon enoughJazuela will become famous soon enough
Well it's a custom code and scripting engine. Its original code was a direct offshoot of C, when it was part of the Iron Crown Enterprises and RoleMaster licensing. Simutronics and ICE ended their relationship and Simutronics had to rewrite specific parts of the game (the parts that the players see) that referred to the old game's "things" such as the various names of towns and streets, critter names, and the like. From that point on, all subsequent coding was done with what they call GSL: GemStone Scripting Language. Unfortunately, GSL and C aren't the most compatible languages in the world, and there have been tons of logistics problems from "fixing" the warrior class to spell implementation and even as far as the creation of new critters and maneuver attacks.

Now, instead of fixing what's broke, they're throwing the dogs a bone, so to speak. Problem is, they're not dogs, but they don't even know that bones come from steak. They're not even listed here as a game on TopMudSites, and hardly any of them even read this or any of the other gaming forums. Many don't even realize there ARE other text games out there, except for a few pay-to-plays that are in competition or created by ex-GemStone staffers.

Kinda sad, eh? But then I was one of those types til last year, when someone said we should vote for our favorite game on this website. The difference between the others and myself (and a few like me) from there, is that the others refuse to even acknowledge that other games not only exist, but could possibly be a learning tool for Simu staff. Those like myself have learned by keeping an open mind.
Jazuela is offline   Reply With Quote
Old 07-14-2002, 06:14 AM   #13
tresspassor
Member
 
Join Date: Jun 2002
Location: Minneapolis
Posts: 45
tresspassor is on a distinguished road
tresspassor is offline   Reply With Quote
Old 07-16-2002, 09:20 PM   #14
Robbert
Member
 
Join Date: Apr 2002
Location: #### Paso, Tx
Posts: 89
Robbert is on a distinguished road
Send a message via ICQ to Robbert Send a message via AIM to Robbert
There is no need to know the specifics of how a particular engine operates, so long as you are aware of the theory behind it.  This applies for internal combustion and rotary, diesel and alternative fuel, MUD and MOO, or any other type of engine, game or otherwise.  Program flow is a necessary aspect of all programming, in all languages.

In the case of a remember-system, hash it on loading the pfile, or pass accessed information to a seperate list, thereby reducing the iterations necessary to achieve resolution.  If this still causes lag issues, then pass it to a daughter process which can function independently, and return back to the parent when closure is achieved.

I'm not sure what GSL is, I've never seen it and most likely never will.  My responses have been purely academic, inasmuch that it bothers me to no end to hear "it's simply not possible" in response to a question about changing the way a articular program or function operates.  Tell me it isn't practical, and I'll drop it, but say it isn't possible and I will come up with numerous reasons to disprove that response.

Gemstone III nets millions of dollars a year in profit.  I do not believe that lack of storage space is an issue.  (Note, however, that I do not advocate the careless use of storage medium; I believe that every program should be written as efficiently as possible, both in terms of operating footprint and storage architecture).


If this is the case then they should not be adding anything new to the system at all, and should be devoting their time to reducing the intercommunication overhead.  I believe, however, that G3 uses an interpreted language system which both slows down their processing system and allows for immediate realization of code changes, similar to the way LPs operate.

By the same token, Tressassor, no ill is meant by this response.

Agreed.  And at some point, it does become self-limiting inasmuch that there is little need, or benefit, in sifting through N-gigabytes worth of data.  The responsibility lies in the programmer to explain at some point that the data should be broken down into more manageable segments, or to do this transparently.  In the specific case of Gemstone and a recognition system, it would be patently absurd to iterate through a 100-thousand person list of names to find the other person in the room with you, and replace their name ("a grue") with the name you have them remembered as ("that awful creature who tried to eat you in the dark last time!").  There are easier ways to do this, some of which have been touched upon in this thread and still many others whose virtues have been extolled in the MUD-DEV archives.

I stand by my statement on efficiency, as it applies to a MUD or other game server.  Lag in the case you referenced would be acceptable, as it is both unavoidable and intentionally-run.  The person requesting the trend report could simply be advised to not do so at a point of heavy traffic.  A MUD, on the other hand, should only require all the resources of a machine during compilation.  I pay for hosting on a 1-ghz machine with 1gb of RAM not because I need the processing power to serve the game, but because I enjoy the speed at which it compiles (as compared to the 200mhz we began on).  I certainly appreciate the comparison you've painted, as I have myself seen it, between older machines and new.

Lag due to congestion is another issue entirely, and can be thrown back to the fact that the protocol suite used to handle most of this was developed in the 60's and is poorly suited for todays speedier machines.  (Although, in tribute to their abilities, it HAS adapted remarkably well - they simply could not have forseen some of the needs to which it would be applied half a century later).

Actually, I believe Gemstone III works in just that way - there's a connection server and a communication server, with data passed between the two as needed.  I'm not positive on this.
Robbert is offline   Reply With Quote
Reply


Thread Tools


Question on Dynamics (Pssst KaVir?) - Similar Threads
Thread Thread Starter Forum Replies Last Post
A question Garud Newbie Help 5 06-02-2006 05:12 PM
Game Dynamics: Utilizing external databases rotm_adm Advanced MUD Concepts 4 10-29-2005 01:10 PM
MUD question Hoj Newbie Help 2 07-21-2004 11:43 AM
Question Nostrum Newbie Help 1 11-18-2002 04:35 PM
A Question weiss Tavern of the Blue Hand 2 05-27-2002 01:50 PM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 05:24 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2022