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 ... 9 10 [11] 12
151
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.

152
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 ;-)


153
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?

154
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.


155
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.

156
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,

157
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.




158
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.

159
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.

160
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.









 


161
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.




162
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.







163
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.     

164
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.

   

165
Design Lab / Re: meta programming and LPC etc
« on: July 25, 2007, 09:49:49 AM »
I actually havent worked on this in some time and my version of the code is rather crude and more of a proof of concept thing rather than a robust implementation. It works for what I wanted it it to do but doesnt trap all exception cases properly I probably will go back and fix this. I did thing somewhat backwards from your suggestion initially which was to instead of have a document with embedded LPC tags was to add extra text function blocks which would be processed to create the metaprogrammed file.

Unfortunately unlike something like Ruby you cannot dynamically metaprogram most LPC variants. This would be alot nicer than this approach but I dont see a way to do this without writing your own server. Here is an example file of what I was working on- it's a bit ugly.

Code: [Select]
---VARSTAT(STAT)
private int $STAT$; private nosave int $STAT$_cache; private nosave function array $STAT$_bonuses = ({});
---

---SETSTAT(STAT, DEPENDS_BLOCK)
// need to update dependencies
public void set_$STAT$(int x)
{
$STAT$ = x;
$STAT$_cache = implode( map($STAT$_bonuses, (: evaluate($1, $($STAT$) ) :) ), (: $1 + $2 :), 0 );
}
---

---ADDSTATBONUS(STAT)
// need to update dependencies.....
public int add_$STAT$_bonus(function f)
{
$STAT$_cache += evaluate(f, $STAT$ );
for(int i = 0;i < sizeof( $STAT$_bonuses );++i)
if( $STAT$_bonuses[i] == 0)
{
$STAT$_bonuses[i] = f;
return i;
}
$STAT$_bonuses += ({ f });
return sizeof($STAT$_bonuses) - 1;
}
---

---REMOVESTATBONUS(STAT)
// need to update dependencies.....
public int remove_$STAT$_bonus(int i)
{
$STAT$_cache -= evaluate( $STAT$_bonuses[i], this_object(), $STAT$ );
$STAT$_bonuses[i] = 0;

}
---

---UPDATE(STAT, FORMULA)
public void update_$STAT$
{

}
---

---GETSTAT(STAT)
public int get_$STAT$()
{
return $STAT$_cache;
}
---

---GETSTATBASE(STAT)
public int get_$STAT$_base()
{
return $STAT$;
}
---

---GETSTATBONUS(STAT)
public int get_$STAT$_base()
{
return $STAT$_cache - $STAT$;
}
---

class stat
{
string formula;
string array depends on;
}


private mapping stats

private string array stats = ({"strength","stamina","agility","dexterity","intelligence","will","eloquence","empathy","constitution","appearance"});

string generate(string array args, function f)
{
return implode( map(args, (: evaluate($(f),$1) :) ), (: $1 + $2 :), "" );
}

string generate_code(mixed array args)
{
return generate(stats, (: VARSTAT($1) :) ) + generate(stats, (: SETSTAT($1) :) ) + generate(stats, (: ADDSTATBONUS($1) :) ) + generate(stats, (: GETSTAT($1) :) );
}

 

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