ID:194483
 
Hey, your MUD sounds really excellent! Any chances we'll have a chance to have a look-see some time soon?
On 2/1/01 6:43 pm Spuzzum wrote:
Hey, your MUD sounds really excellent! Any chances we'll have a chance to have a look-see some time soon?

Probably not soon, I'm at least four months from completion. Changes in my job leave me little personal time, but it is my New Years resolution to get this thing out and done with, so sometime this year it will be out.

I've actually had a working model that could have been published several times in the past couple years, I've just discovered better ways of doing things or ran into problems in the next step of coding which required a different approach.

For example, in the past year I was using an object oriented basis for coding by putting all the verbs with the objects they effect (obj/verb/get for example) but when coding something else I discovered that I couldn't do it this way, that I needed the verbs to be based on the mob instead.

Other problems were loops that took up resources and had to be streemed down (I don't know if they would have effected performance or not, but figured better to clean it before distributing it). I'm still not certain how well I'm doing here - I've narrowed everything down to lists, with a couple global procs which check the lists for objects which need to do things and then have them do it, but there is a constant overhead where every 1 and 12 seconds the system runs through lists of objects, executing scripts. It's not as bad as searching everything in the world.contents, but it grows with the number of people playing the game.

Containers remain a problem still, but I think I have something that will work.

Doors, walls, buildings, and the players ability to build is done but I need to put in management utilities so that a ruler can manage his/her kingdom (tax shopkeepers for example). I'd originally had all of this through HTML scripts, but I think I'll opt for security and use a standard MUD-text menu.

The help system is complete (browser based).

Multiple characters are still out, but I may change this once I start playing with the save routines again.

So I now have a couple working models from which I'm basing my current project and I just need to make time to mesh them together and iron out the details.

My current schedule:
1. Create a working model with the major systems in place (June)
2. Finish the AI and magic systems (September)
3. Alpha-Beta testing (November)
4. Publish codebase and source (January 2002)


In response to Gabriel
Your program sounds like it will be quite impressive!

For example, in the past year I was using an object oriented basis for coding by putting all the verbs with the objects they effect (obj/verb/get for example) but when coding something else I discovered that I couldn't do it this way, that I needed the verbs to be based on the mob instead.

One thing occurred to me when I read the above paragraph: have you considered something like this for verbs like get()?

obj
var/gettable = 1

verb/get()
//bla, bla

New()
if(!gettable) verbs -= /obj/verb/get

gold_coin
//gettable = 1 by default

gas_cloud
gettable = 0

In response to Guy T.
On 2/5/01 1:46 pm Guy T. wrote:
Your program sounds like it will be quite impressive!

For example, in the past year I was using an object oriented basis for coding by putting all the verbs with the objects they effect (obj/verb/get for example) but when coding something else I discovered that I couldn't do it this way, that I needed the verbs to be based on the mob instead.

One thing occurred to me when I read the above paragraph: have you considered something like this for verbs like get()?

obj
var/gettable = 1

verb/get()
//bla, bla

New()
if(!gettable) verbs -= /obj/verb/get

gold_coin
//gettable = 1 by default

gas_cloud
gettable = 0

Yep, that's how I had it originally. I've had to change it though - this was only one example of many. In this case, I think the problem was with hidden objects.

If an object is obj/var/hidden=1 and certain mobs know of it's location, then they should be able to pick it up. I couldn't restrict it to only the mobs that could see it when using an obj/verb/get() command (I think this was the issue).

What I had to do instead was use the variable obj/var/gettable=1 and put the verb with the mob (which calls a process which generates a list of gettable objects in range of the mob and which are not hidden from the mob).

Which reminds me of the other issue... How to prevent an object from showing on the map if the mob can't see it but show it to the mob that can see it... I was supposed to take a look at that a couple weeks ago -g-.

For my own notes so I don't forget -
It may be possible to mask the object using a clear icon but the name may still show up. Need to test it to make sure - if the name does not show, or if on a right-click it doesn't show up in the list, then this should work. Otherwise I'll have to figure something else out.

In response to Gabriel
Which reminds me of the other issue... How to prevent an object from showing on the map if the mob can't see it but show it to the mob that can see it... I was supposed to take a look at that a couple weeks ago -g-.

Probably you've considered this, but just in case, I'll mention it: in general, the image() proc is tailor-made for this type of thing. Basically, image() is kind of a "fire-and-forget" procedure; as soon as you know the mob can potentially see it, you just do

myMob << image(icon, location)

and let it go at that. Even if the mob is halfway across the world, the image will show up when the mob comes within range. But I think there may be some kind of catch here too--I think you have to keep a reference to the image or it will be automatically deleted. So you might need to replace the preceding with

var/K = image(icon, location)
myMob.currentImages += K
myMob << K

Hmm, and then you'd have to support a way to remove the image when it's no longer needed too... dang, I'd give it more thought but I'm in kind of a goofy state of mind (should've taken a vacation day to recover from vacation!).

Ah, now this has me wondering... there's a difference in syntax between image(), overlays, and underlays, yet they all seem to do very similar things... wonder if it would make sense for Dantom to update the syntax so you could replace a call to image() with

myMob.images += K

(Of course, image() could still remain backwards-compatible.)

In response to Guy T.
(Of course, image() could still remain backwards-compatible.)

I think Gabriel's game is text-based.
In response to Spuzzum
On 2/5/01 6:30 pm Spuzzum wrote:
(Of course, image() could still remain backwards-compatible.)

I think Gabriel's game is text-based.

80% text, but I found it easier to play with a graphic map in regards to selecting multiple objects with the same name. Besides that, I wanted a visual reference to a map and directional relations. So it's mostly text, but the graphic element is there for reference and, to a limited degree, assistance in cases where mutliple objects exist.
In response to Guy T.
On 2/5/01 6:12 pm Guy T. wrote:
Probably you've considered this, but just in case, I'll mention it: in general, the image() proc is tailor-made for this type of thing. Basically, image() is kind of a "fire-and-forget" procedure; as soon as you know the mob can potentially see it, you just do

myMob << image(icon, location)

and let it go at that. Even if the mob is halfway across the world, the image will show up when the mob comes within range. But I think there may be some kind of catch here too--I think you have to keep a reference to the image or it will be automatically deleted. So you might need to replace the preceding with

I've been thinking about for a bit; The only problem I can see is that if I have five hundred people logged into the game, and all of them are hiding an object from each other, then someone finds it and unhides the object, I'll have to target every mob in the game with multiple image() commands. That strikes at the "effeciency" side of the game model so I'm not sure how viable it is.

Something to think about anyways :)