[DGD] DGD good choice for MUD with large-scale city simulation?

[bart at wotf.org]

On Thu, 6 Dec 2018 09:42:04 +0000, Da'ud Vyd wrote
> Hi folks,
> 
> I've developed a curiosity about DGD and was hoping you all might be 
> able to guide me toward a decision
> 
> about which tools to use for a project. In short, my understanding 
> is DGD is a combination database and
> 
> object mapper that requires a mudlib in order for someone to use LPC 
> to build a MUD. Is that more-or-less
> 
> correct? 

Yes

> If so, what mudlib is currently recommended for use with DGD?

I think this quite depends on what direction you want to take. For new
projects with a design that doesn't fit the traditional lpmud approach, I'd
look at cloudlib, but you'll have to do a lot of work yourself to turn this
into a game supporting lib. That said, with a non traditional design this will
be true for every lib you use.

> 
> Do DGD and mulibs attempt to capture/recreate past programming 
> paradigms or are they current? For example,
> 
> can they take advantage of modern multiprocessor CPUs? On a machine 
> with 6-processors, a fast SSD drive,
> 
> and 32gb of RAM, how would DGD compare against MySQL or PostgreSQL?

That is comparing apples and oranges. DGD is not and does not attempt to be a
sql database. While it is possible to create an sql like interface on DGD (I
did so for one of my toy projects), its not what it is good at. It is an
object database that primarily works based on references and object identifiers.

As to taking advantage of multiple CPUs, you'd need DGD's bigger and
commercial 'brother': hydra (see Felix' post about that).

As to current libs, Gurbalib is probably the most complete one with regards to
offering game functionality, and may be a good starting point for learning
what DGD is about and how to (not) do certain things. I do however think it is
not the lib you are looking for for the kind of game you are describing. Being
one of the co-authors of current gurbalib, I'd say you need to strip away
almost all game functionality and reimplement it with a model more appropriate
to what you want. Gurbalib can support virtual rooms and such, but is built
around the idea of traditional 'coded' rooms like a classic lpmud uses. I
think for what you describe, you need something that has been designed from
the start for supporting 'virtual' rooms.

Imo much of the setup you describe also depends on having a smart data model
which reduces the amount of real work that needs to be done. That data model
should be one of the foundations for implementing the game functionality.

> 
> I'm planning a MUD that has a lot of non-standard functionality, 
> including an underlying city simulation
> 
> in which objects (e.g. non-player characters or "mobs") are always 
> active, building emergent story lines.
> 
> Ideally, I'd like millions of active objects. However, due to 
> performance constraints I may need to get by
> 
> with a few thousand.

A few thousand should not be an issue. I run DGD instances with a few million
objects, many of those being active lots of the time, and this is possible as
well, but it requires more care, especially it requires making sure DGD gets
to do its housekeeping tasks often enough, and hence ensuring no code ever
hogs the system.

> 
> I'm familiar with scripting (Python & R) and have played with modern 
> compiled languages (Go). For my project,

I'm not sure those are of much help other than having some general experience
with implementing algorithms. 

When looking at 'modern' environments, one that comes close to the kind of
programming model you need to use for any LPC based programming environment,
DGD included is nodejs. DGD, and pretty much all LPC variations, is event
driven, and for using it successfully you must really wrap your head around
this event driven model, and let go of the typical approach most programming
environments get you. 

For example, the simple idea of asking the player to answer a question in a
traditional programming language would be something like (pseudo code):

void askQuestion() {
  write "some question";
  answer = getInput()
}

On DGD and other LPC based environments, you need something different:

void askQuestion() {
  write "some question";
  input_to( "getAnswer" );
}

void getAnswer(string str) {
  answer = str;
}

In this, the getAnswer function gets the player input, it *MUST* be its own
function, and it will be called once the player provided input.

This model must make sense to you, and you should realize every interaction
must follow such a model, and cannot use the first model. In fact any change
to your data should follow such a model.

> 
> I've considered evennia<http://www.evennia.com/>, which is wonderful 
> but works in a single thread--so not good for a city simulation.

Those 2 things are not mutually exclusive. It being single threaded does mean
it won't work with a traditional approach with 'main loops' and threads for
everything that needs to happen, but, it can work very well for an event
driven model.

Note that an event driven model lets you 'multiplex' many different chains of
events, and effectively let you create something that appears to execute many
different things in parallel. It won't let you take advantage of multiple CPUs
however unless the underlying engine does (Hydra for example)

> 
> coffeeMUD<https://github.com/bozimmerman/CoffeeMud> is multi-
> threaded but written in Java, which is completely alien to me.
> 
> Would you recommend DGD for my project? If not, do you have a 
> different suggestion?

DGD, and when you scale up, possibly Hydra.

My advice however would be to first of all spend time on how you are going to
model your data and interactions, and on deciding if an event driven model is
workable for you. If it isn't, than neither DGD nor Hydra will work for you,
but if it is, I think DGD would be a very good starting point. Either way, you
have a lot of work ahead of you, for what looks like a very nice project.

Bart.
--
https://www.bartsplace.net/
https://wotf.org/
https://www.flickr.com/photos/mrobjective/