Top Mud Sites Forum - View Single Post

Robbert · 07-16-2002, 09:20 PM

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.

07-16-2002, 09:20 PM	#14
Robbert Member Join Date: Apr 2002 Location: #### Paso, Tx Posts: 89	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.