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, 01:58 PM   #1
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 843
Jazuela will become famous soon enoughJazuela will become famous soon enough
KaVir or anyone else who's *well versed* and can explain to me as if I was a total moron (in other words, no code snippets please - plain Inglush! )

I'm having an arguement in a forum for players of another game (no, not the one I play now, one I used to play and still contribute and moderate the forum). There's these changes going on, and I thought they were horrible while the gamers are extolling their virtues. I tried to explain how there are games out there that do SUCH a better job, including (but not exclusively) implementing dynamic descriptions. It was just an example, to show them how limited these players are in what they're getting, compared to what's out there AND compared to what their IMPs promised over a decade ago.

The counter to my dynamics example was that in a game of hundreds of thousands of characters (most of which are "storage" characters that never get played, they just hold stuff for their alts), a "greeting" system would be impossible given the limitations of data base size. That every time someone introduced themselves there would have to be a check in both characters' data file, and with that kind of player population it wouldn't work.

The guy completely glossed over the "The man you're looking at appears to be sllightly taller than YOU" thing, but I guess that same concern would apply.

Is this type of dynamic coding feasable in a massively populated text-based game, or would the sheer number of datafiles make implementation more of a nightmare than it's worth?

Thanks,

Me
Jazuela is offline   Reply With Quote
Old 07-13-2002, 02:29 PM   #2
tresspassor
Member
 
Join Date: Jun 2002
Location: Minneapolis
Posts: 45
tresspassor is on a distinguished road
Quote:
Originally Posted by
Is this type of dynamic coding feasible in a massively populated text-based game, or would the sheer number of data files make implementation more of a nightmare than it's worth?
Hrm, i'm having some problem understanding the whole question... is it something like this:

Each player's description would be dynamic in relevance to your description?

So when you look at a player they would do something like this:
Joe
Joe towers above you, muscles that you didn't even know exist ripple along his forearm. He is smarter then you as well, you dolt!

Then you were talking about a "greeting" system.

So from what i read, does that mean a greeting system like when you enter a room you'll see:

The Tavern of The Blue Hand
A nice big restaurant/bar with easy going waitresses.
You see: a woman, a woman, a woman, a woman, a guy, a guy, Torinlador, Creptindor, and Jolindar here

And when A guy says: "Hey my name is UbRoxor666! then when you look again you'll see UbRoxor666 there.

Both of these changes aren't that hard, the second "greeting" system is a heck of allot more taxing then the first one.
------------------------------------------
The first one, the "comparison" system isn't that big of a deal, in both processing and data... As Long as it's only done when you Look at the person.

The only real problem that comes with the "comparison" system is how much of that data is already stores, example:
When players start the game they enter in their height, weight, age, race, sex, hair color, eye color, and shoe size.

Now its relatively easy to take all that information and compare it, but if none of that was built into the game then the data needs to be set for all of the players out there, and if there's thousands of players implementing that can get to be a real nightmare.
------------------------------------------
The "greeting" system would be allot of extra storage, i've seen the code for this on various games and when there are high #'s of players it can get to be allot of bloat.

Basically you need to remember the player, and the name that the player gave you, and when you look in a room each player needs to be compared in the list of players you have stored.

Since this system seems to be focused around anonymousinity (real word? don't think so ), there should be a way for a player to wipe his information from all the other player's that knew his name, either by changing his/her appearence through the use of magic or plastic surgery, or possibly marauding as a different player.

Another problem with the "greeting" system is implementing it on an allready existing game. If you have thousands of players you really need to test this system to the extreme.

When implemented each player could be adding up to 1,000 names in their "known player list", if each player held 10% of that  you are looking at 100 names per player, wich is alot of data to store per player. So the smallest error or bug could seriously bloat the database.

I don't think its necessarily that good of a system, but that's my opinion and from talking with other people its almost 50/50 on people that like it vs people that don't.
------------------------------------------
So in short, depending on how the first one was built it could be easy or hard

The second one would be more difficult to implement on an allready existing game, and you run the risk of only half the player-base liking it.
tresspassor is offline   Reply With Quote
Old 07-13-2002, 03: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.

Quote:
Originally Posted by
When implemented each player could be adding up to 1,000 names in their "known player list", if each player held 10% of that you are looking at 100 names per player, wich is alot of data to store per player. So the smallest error or bug could seriously bloat the database.
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".

Quote:
Originally Posted by
The first one, the "comparison" system isn't that big of a deal, in both processing and data... As Long as it's only done when you Look at the person.

The only real problem that comes with the "comparison" system is how much of that data is already stores, example:
When players start the game they enter in their height, weight, age, race, sex, hair color, eye color, and shoe size.

Now its relatively easy to take all that information and compare it, but if none of that was built into the game then the data needs to be set for all of the players out there, and if there's thousands of players implementing that can get to be a real nightmare.
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, 04: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, 06:21 PM   #5
tresspassor
Member
 
Join Date: Jun 2002
Location: Minneapolis
Posts: 45
tresspassor is on a distinguished road
Quote:
Originally Posted by
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.
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, 06:28 PM   #6
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 843
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, 07:14 PM   #7
Robbert
Member
 
Robbert's Avatar
 
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, 08:12 PM   #8
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 843
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, 08: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 Mud Companion magazine. So I do have some familiarity with the subject at hand.
KaVir is offline   Reply With Quote
Old 07-13-2002, 08:56 PM   #10
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 843
Jazuela will become famous soon enoughJazuela will become famous soon enough
First of all KaVir, I LOVE your tagline. It tempted me (okay almost tempted! to light my lantern.

Second, it isn't about race recognition - I mean, the documentation of the game tells all players which races have which characteristics, so it's not out of the expected to KNOW that you're looking at a dwarf, or a giant, or a halfling, or human, etc.

It's knowing where that dwarf comes from - which clan that the arguement was about. I mean, c'mon, how can I possibly know just by looking at one particular dwarf which clan he's from? If the character gen process allowed for each clan to have specific features that were exclusive to that clan, then it would make good sense. But it doesn't, and they don't have any plans for it that they've announced.

It just seems like a really shoddy "bone" to throw the players when they're paying for steak.
Jazuela is offline   Reply With Quote
Old 07-13-2002, 09: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
Quote:
Originally Posted by
It's knowing where that dwarf comes from - which clan that the arguement was about. I mean, c'mon, how can I possibly know just by looking at one particular dwarf which clan he's from?
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, 11:19 PM   #12
Jazuela
Senior Member
 
Join Date: Apr 2002
Location: New England
Posts: 843
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, 07:14 AM   #13
tresspassor
Member
 
Join Date: Jun 2002
Location: Minneapolis
Posts: 45
tresspassor is on a distinguished road
Usually I spend alot of time writing a post and wind up never sending it, probably because i don't want to wind up accidently offending someone. But i've been writting and re-writing this for the last hour, so i'm going to post it!

I agree with most everyone has been saying. But I'm still going to play devil's advocate and side with the developers of the game for the moment

I'm not famalier with the standard MUD codebases wich is why my reasoning may differ from others.

Quote:
Originally Posted by
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.
That does have a huge impact on wether or not something would be "easy" to implement.

Since this is a custom code-base i don't think many of the opinions or suggestions would have any relevance, not mine or anyone else's unless they worked in that custom codebase, or are familiar with its structure (of course everyone but me may have in depth knowledge of this codebase, if so, i apologize ).

I really can't offer much factual information because I have no idea what this codebase is like, so i can only offer opinions, and what i know in terms of application development.

So, to point out differences in various codebases i'm going to talk about MOOs for a second.

Basically moo has its own programming language, similar to c. All information is saved in 1 db file, (there are other files that determine the core effects of moo, but everything you create, all players, and anything else are saved in that 1 db file).

If you add 12k per-player, take that 12k and multiply it by the # of players  (100,000) and you get how much data would be added to the db file (1.2gigabytes) to implement a vector "greeting" system. In MOO this is a pretty big deal.

Another MOO weakness is vectors, you have to be careful when looping through large amounts of data else you'll lag the game and/or spit out task-ran-out-of-tick errors at the players. It can be done on occasion, but you'd definitely never want to be looping through thousands of elements every second. Now in standard 1-D vectors {1,2,3,4,5} its very simple, but there is no pretty way of handeling Nth-D {{1,2},{3,4},{5,6}} other then looping through the entire thing each time you want to find out what "3" is paired with.

So those are a few differences that MOOs have. There are more, but that's just an example of how different codebases can be.

In order to determine what is easy to implement or not easy to implement you really need to get into the structure of this custom-codebase.

#1: How is their structure, how does this custom codebase work, what is its strengths and what is its weaknesses.
#2: What is GSL like, how fast is it, how much can it handle under normal circumstances, what is its breaking point?
#3: How much of the game is GSL and how much of it is C? Is there allot of overlap between the two?
#4: What is already broke and what would it take to fix it?

But another important thing is to really ask the admin is "why cant (increddibly cool idea) work". Find out specific semi-techincal reasons.

I mean, if you wanted to implement a very in-depth dynamic system that involved storing lots of additional information on each player then bloat is an important factor. Robbert is right that a database can hold any amout of data, but if the total sum of everything they are adding is 12k per player or 1.2g total, can they afford that much space on their server? Sure its not that much, but are they taxxed out to begin with? And do they even want to put that much information on there?

Or processing, if they have some things writtin in C and others in GSL then they may have enough problems just trying to hold things togethor and migrate old code to the new code. They may not be able to afford that much overhead.

-----------------------------------------

But, getting back to the actual system of Guilds/Clans showing up in the player's description:

There are plenty of really easy / lag free ways to do what you were describing. Earlier I was confused about what sort of dynamic content you meant. And when I finally got it, it seems rather straightforward. So I apologize for my earlier unhelpful replies.

"Lag/Bloat Free" ways to do it:

#1: Make it run off of intelligence/race (if you are a dwarf you can recognize all other dwarven clans, if you have a high enough int you can pick out clans from any race)
#2: Make it run off of a new skill (Dwarven Lore, Elven Lore, Human Lore, the better you are at the skill the more likely you are to pick up on what clan a person is from).
#3: Just not show it at all, be it something they have to tell you and you have to physically remember it.

Clans/Guilds are kind of like sub-races to me. Basically you should be able to recognize a Dwarf from the Black Hills clan because of his "blue anchor tattoo" or "pitch black beards" or something to that effect.

By making this information based off a skill, race, or stat you minimize the overall amount of data that needs to be stored per player. You don't have to store any data actually, its just a standard check.

-----------------------------------------

A few other things: Robert if i'm taking these quotes out of context, or missinterpretating them let me know i'll remove them, and I apologize (its 5am) .

Quote:
Originally Posted by
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.
---
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.
To continue on with devil's advocate: A database is not really unlimiting, i mean it falls into the constraints of any application: if your Database server has a 200g hard drive there is no possible way for it to hold more then 200g worth of data. So if the machine that is holding their information is using 90% of their storage capacity then its time to tighten the belt on data-heavy enhancements until you can get more space.

But yes, that is common knowledge, but I'm just saying it because usually when an application is built you very rarely want to move it again because the more you make hardware changes the more likely you are to break something.

If this game was built 10 years ago it could have been upgraded 2 years ago and only have 20g worth of storage. Given it is a heck of alot of storage for a MU*, but i dont know about a MU* with Hundreds of Thousands of players. Especially in the way that Jazuela describes, it makes me feel like there is alot of unused data, lots of processes that are from the old days, lots of "fat" in general.

More then likely my point here has no relevance, I would bet they have very fast machine with alot of free space (especially if they have that many people online).

And MU*s dont fit the common web-application mold so they would be easier to port around (since its 1 box 1 application rather then an app server, database server, and 60 other machines all networked togethor in a hodge-podge of duct tape and chicken wire).

Quote:
Originally Posted by
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.
I really cant 100% agree (I 98% agree ). I do believe that 98% of all lag in any application is because of code, where i work now that is normally the case. But just because there is lag it doesn't mean that there is a code problem. Lag happens for a reason, but sometimes those reasons are out of your control.

What i mean is: 5 Years ago I was building an intranet for one of my former employers, the computer I was using as the web server was a P2 (200 mhz i think, i really don't remember), 32m ram, 8g hard drive. It was running IIS and cold fusion server. The main intranet application was a set of standard SQL queries on a DB2 database in the other room. That DB2 database had about 500k+ records of data (12k records were added each day). In order to effectively run this application over 60,000 records had to be returned and processed to create a trend report.

No matter how hard i worked I could not get this application to run under 1 minute, just because it was bottle necking at the crap P2. But i did manage to get it down from 10 minutes to 1.5 minutes by spending a few days and seriously optimizing my code.

It is possible that I could have gotten it faster by re-optimizing my code, but I dont think so, this was along time ago. From what I remember, it took over a minute just for IIS to get the data from the DB2 box. And once again there is the possibility that optimizing the SQL scripts would have made that even faster, but i really dont think so. Alot of processing had to happen on alot of data.

Hardware is just as important as code. Given, if you use a good framework (like eXtreme Programming) allot of your lag based problems will go away, but not all of them will. And that's true with any application, some things will just have to take time.

Another more valid example is screen scraping, if the only way to get data is to parse out a text file (which is what you have to do when trying to get airfare information from any of the major GDSes) its going to take time, no matter how optimized your code is, parsing out 30,000 characters of data per PNR when you need to do it for 500 PNR"s is just going to take time, plain and simple. That's why when you search for airlines on travelocity, or expedia or other places it has a "please wait" screen.

I think MU*s fall into that same category. They are software applications and some things will just take more time then others. Given text based games don't NEED to have that much processing but when you sum it all together there still remains the possibility of lag. And maybe you are right that all lag revolves around un-optomized code, I'm sure that all lag in my game does , but I just cant fully agree that its 100% true all of the time.

-----------------------------------------

To end: I don't know anything about this particular game, its codebase or the people on it. All I'm trying to say is its difficult to have a cut and dry answer for general questions such as this when they deal with a specific game. There are too many important factors to consider to really nail down as to if it is a simple or not-too simple enhancement.

Even if the game was a diku derivative or something common, its sheer number of players means there's probably been thousands of developers and who knows what would be left from the origonal code-base, or what the code even looks like now (i'd guess it looks more like a Work of Art then code by now)
tresspassor is offline   Reply With Quote
Old 07-16-2002, 10:20 PM   #14
Robbert
Member
 
Robbert's Avatar
 
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
Quote:
Originally Posted by
Since this is a custom code-base i don't think many of the opinions or suggestions would have any relevance, not mine or anyone else's unless they worked in that custom codebase, or are familiar with its structure (of course everyone but me may have in depth knowledge of this codebase, if so, i apologize ).
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.

Quote:
Originally Posted by
Now in standard 1-D vectors {1,2,3,4,5} its very simple, but there is no pretty way of handeling Nth-D {{1,2},{3,4},{5,6}} other then looping through the entire thing each time you want to find out what "3" is paired with.
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).


Quote:
Originally Posted by
Or processing, if they have some things writtin in C and others in GSL then they may have enough problems just trying to hold things togethor and migrate old code to the new code. They may not be able to afford that much overhead.
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.

Quote:
Originally Posted by
To continue on with devil's advocate: A database is not really unlimiting, i mean it falls into the constraints of any application: if your Database server has a 200g hard drive there is no possible way for it to hold more then 200g worth of data.
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).

Quote:
Originally Posted by
And MU*s dont fit the common web-application mold so they would be easier to port around (since its 1 box 1 application rather then an app server, database server, and 60 other machines all networked togethor in a hodge-podge of duct tape and chicken wire).
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 06:12 PM
Game Dynamics: Utilizing external databases rotm_adm Advanced MUD Concepts 4 10-29-2005 02:10 PM
MUD question Hoj Newbie Help 2 07-21-2004 12:43 PM
Question Nostrum Newbie Help 1 11-18-2002 05:35 PM
A Question weiss Tavern of the Blue Hand 2 05-27-2002 02: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 11:19 PM.


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