Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - silenus

Pages: 1 ... 10 11 [12] 13
166
Design Lab / Re: new server design- call for features
« on: September 22, 2007, 06:11:43 PM »
I guess an interesting question is how best to exploit a database backend in storing mud data. Ideally it would be nice if you could index all objects and perform complex queries on them. From my limited experience there is a certain amount of book keeping type activities in most muds and potentially could can store a vast wealth of data which needs to be maintained in some manner and queried.

Some examples of this include statistics on stuff like who has kill which mobs with what spells and so on. Obviously for a LPmud style driver since none of the objects are hard coded there would need to be a general interface to still stuff while maintaining object integrity and security for the systems data.

I have been wondering if one might use a more powerful query engine and layer it on top of SQL some that maybe supports a larger subset of FOL (first order logic) such as XSB. The storage capability and reliability of an SQL backend is one of it's great strengths but the query language cannot adequately handle recursive queries which might be sometimes need to ferret out information about the system.

How good is PostGres in supporting fuller FOL semantics or are there alternatives to using say a theorem prover such as XSB (but this isnt really a storage system).

167
General / Re: name generator
« on: September 21, 2007, 05:59:34 PM »
I really don't know much about this area either but here is my 2 cents. I recently saw a pretty realistic natural language generator which relies on stochastic models by fitting against existing papers. It produces complete gibberish but it's grammatically correct and sounds reasonable. My suggestion might be to consider looking at a name set of reasonable names (this might be hard to come by since they are fantasy names after all) and use them to fit a Markov model of some sort to the data.

168
Design Lab / Re: new server design- call for features
« on: September 20, 2007, 04:58:41 PM »
I perhaps meant being concurrent without being either multi-processed or multi-threaded at least from the perspective of the would be mud developer.

Certain language designs are concurrent without being explicitly multi-threaded. examples include various functional language flavours i.e. CLEAN, Erlang etc. CLEANS primitives are decidely simple but explicit. You can even go the implicit (for FP) route but so far this problem seems so difficult that no one has solved the problem (efficiently).

Erlangs primitives are slightly different. They are completely message based. So in principle you can design things around the multi-process multi-threaded models though ultimately given how systems are designed you will be implementing in these paradigms at the OS level. Or at least that's my understanding of some of these different non multi-process multi-threaded paradigms ;-)


169
Design Lab / Re: new server design- call for features
« on: September 20, 2007, 03:32:18 PM »
I guess I am basically wondering if I can be concurrent without being multithreaded. I.e. from the servers standpoint it would be implemented as a multi-threaded system but the language and system design would be explicitly concurrent (unlike DGD/MP which I think tries to exploit concurrency more or less implicitly).

I have been wondering about Erlang's message passing model or whether some other concurrent model could be used which have the same speed up advantages of a multithreaded scheme. It might even be nice to perhaps consider certain types of distributed processing under something like MPI. Or would that be overkill for a mud server?

170
Design Lab / Re: multi-threaded versus single threaded mud servers
« on: September 19, 2007, 07:46:23 PM »
Yes I have done some debugging of multi-threaded code and from my limited experience it's not pleasant. On a multicore platform even reproducing the error could be problematic since it might depend on if and when the thread of execution A executes instruction X relative to when thread of execution B does so.

I think someone published a paper call the problem with threads indicating that the amount of nondeterminism in the threading model makes coding of such systems in general perhaps too difficult and hard to debug. The thing I have been trying to look at is are there other types of parallel models or ways to make these sorts of things easier to debug before selecting to implement them into a mud server design.

My understanding is that certain languages have better built-in primitives than threads that could perhaps help alleviate some of the problems of programming in a thread model. Erlang again perhaps but I have yet to explore this avenue.

As to whether you can hit the CPU ceiling- I feel there are certain things you can do on a mud which are quite CPU intensive. One example is certain forms of pathfinding via A* which I find consumes alot of CPU time. I could think of other usages such as minimaxing AI's for combat etc. depending on the combat model and so on.


171
Design Lab / Re: multi-threaded versus single threaded mud servers
« on: September 19, 2007, 03:43:00 PM »
One issue that concerns me is how much performance will the lock entry and exit code soak up for the mutex's. Making code thread safe often means the code will run slower so this offsets some of the speed up again you gain from MP as well.

172
Design Lab / multi-threaded versus single threaded mud servers
« on: September 19, 2007, 12:35:19 PM »
I am in the early stages of designing a new driver which hopefully I can implement over the course of time. One issue for me is the advantage and extent that multi-threading should be used in a driver or server design. I know for certain types of applications the speed up you get from using OS threads might be quite limited. I am curious if mudding is one of those applications where if you even exposed fully a nice parallel model that was easy to work with and fast would the inherent limitations of the application restrict the speed up.

I would be curious to hear different peoples opinions on this.

Thanks in advance,

173
Design Lab / Re: new server design- call for features
« on: September 19, 2007, 09:43:26 AM »
I am not sure initially how close I will be sticking to the basic language design of LPC. If I do embark on this multi-stage project I think my initial targets will be to get a solid VM design completed with a rudimentary language interface. To support metaprogramming I suspect I will include some sort of subsystem that has some resemblance to (: stuff but the syntax might not be the same.

As for the MP issue. I think I heard that Dworkin was working on something of that nature since I do subscribe to the DGD mailing list. However I am not sure what his plans are really in this area. I noticed certain things are in the current DGD release such as atomics and some sort of I think serialization and rollback code which makes it all invisible. Perhaps you know more about it than I do.

I suspect I might want to actually have a parallel programmable model of some sort but this might me more work than I am willing to put in at this time but I will have to research it some more. Perhaps a language like Erlang is worth a look.




174
Design Lab / Re: Perlin Noise and The World(TM)
« on: September 17, 2007, 12:34:09 PM »
Hi,

I had considered something of a similar nature but ran into some road blocks. The main problem is the natural language generation part of the problem for generating virtual descriptions which are reasonably readable and realistic given a variety of extenuating circumstances- i.e. weather, seasons time of day.

The problem is of course I am not sure how best to build a good natural language generator given some description but i suspect it's possible since they have done it for other things like the weather or some toy problems in news article generation etc.

The problem is Perlin noise here might be more of an analogy and cannot be directly applied in a non graphical setting i.e. text based- but perhaps some elaborate scheme could be dreamt up that could make this work.

175
Design Lab / Re: new server design- call for features
« on: September 17, 2007, 12:04:57 PM »
I am thinking increasingly I might use an SQL db to store most of the data in the system. Most likely I will make the project GPL as well. I am currently looking into what sort of issues would arise if the system ends up being multithreaded. I suspect I will perhaps drop the graph based VM design since it is perhaps not so good for a system which is fundamentally O-O as opposed to a pure functional language.

176
Design Lab / Re: new server design- call for features
« on: July 27, 2007, 05:58:25 AM »
I am not sure how close to MudOS my language design will be initially but I suspect it might not be too close since support for MudOS isn't really one of my primary goals- I would more like to push the feature set forward on other fronts and have sort of a modernized "next-gen" driver rather than recreating an existing driver.

I am not sure what you mean by enhanced shadow support. Is LDmud's shadow system different than the one in MudOS? I am not sure if I have full metaprogrammable/reflection features if this sort of feature might be redundant as well. I guess I might have to subscribe to the LDMUD mailing list and see what sorts of features LDMUD has in contrast to MudOS and DGD.

As for an API layer I am not sure if it's possible to do this without writing multiple compilers since I have my own VM design. If it was an API layer, the main question is how to do it in a safe secure manner.









 


177
Design Lab / Re: meta programming and LPC etc
« on: July 26, 2007, 10:36:39 AM »
Thanks guys. I think I might have figured out a way to get what I want under MudOS. It probably again as clean as I would like either but a combination of shadows/generative programming might make what appears to be dynamically metaprogrammable objects possible along with some other interesting features. Making it all secure of course might be an interesting challenge.




178
Design Lab / new server design- call for features
« on: July 25, 2007, 01:03:20 PM »
I have been considering building a new server for muds and this is a project which is still in the early planning stages. I have certain features mapped out and others which I am still debating how best to implement. However my main problem is that currently I dont have enough features to differentiate myself from the current generation of servers. I am curious what sorts of features people would like to see if such a project were brought to fruition.

Some current features I have been considering include-

functional language design
a graph-based virtual machine.
persistence(via XML)
metaprogramming/reflection support
support for distributed middleware such as ICE/CORBA
builtin security kernel(capability based or ACL based)


Thanks in advance,

Silenus.







179
Design Lab / Re: meta programming and LPC etc
« on: July 25, 2007, 12:34:12 PM »
I think the SKOTOS for DGD had some similar scripting language on a scripting language called Merry and ended up writing alot of their lib in a modified script language. The file you posted also reminds me of the UNQ system in Phantasmal even though the goals for that a decidedly more modest (it's a data format like XML which is used to specify object data without having to add any setup code in  create per usual LPC development).

My goals for having a metaprogramable LPCish toy (at least generatively) are probably more modest. I actually wanted to be able to do dynamic metaprogramming of some sort in LPC but this is perhaps mostly impossible currently. I.e. i thought it would be nice to be able to interogate objects (reflectively) and update them on the fly such as adding new functions using LPC code but I ended up settling initially on just having generative style code.

To make it more robust I suspect I would have to do a better job of parsing through the LPC in the file.     

180
General / Re: Wikipedia article on LPmud
« on: July 25, 2007, 10:41:37 AM »
Aye you are correct. I guess digging out relevant references to reference materials has become so second nature to me that I even forgot to mention it  :o. I thought perhaps the historical section could become part of a larger article where perhaps you could get away with it by referencing everything else. There are actually some references in a related article on wiki on muds in general. This perhaps might be a good starting point for changing the article so that it has more appropriate content. This gives a broader historical outline and contextualizes mudding within the context of the rise of the MMORPGs. I was actually surprised that there are a number of research articles on muds in general in the literature including this one- http://www.ics.uci.edu/~jpd/publications/mud-intro.html.

   

Pages: 1 ... 10 11 [12] 13