17 Jan, 2013, Kelvin wrote in the 41st comment:
Votes: 0
I think the better phrasing is that distributed systems can make things more difficult to debug and expand. This is very much the truth. Tying this in the article, it's important to make sure that you really do need some kind of distributed MUD right out of the gate, when, again, we're building GoCarts, not Ferraris.

This question will be different for every game developer, but don't go distributed (whatever your interpretation of the word means) just to say you're distributed, unless you're one of the aforementioned people who doesn't really care much about launching.
17 Jan, 2013, Rarva.Riendf wrote in the 42nd comment:
Votes: 0
Quote
So how do they make it harder to maintain and upgrade?


Complexity, more complexity will always makes something harder to maintain and upgrade. If you don't NEED it, don't do it.

It is like multithreading, sure you can get huge gains from it, but unless you actually need the gain, avoid it at all cost.
Going from 10 minutes to 1 in a process seems great at first but if that can be launched in the night as a batch…already another story. Unless you actually need those 9minutes, you shoudl prefer the possibilty to maintain and update your code easily instead.
17 Jan, 2013, Kelvin wrote in the 43rd comment:
Votes: 0
Also important to note is that being distributed alone does not make your system easier to upgrade, share, more fault-tolerant, or error-resistant, just like using MongoDB and Node.js doesn't instantly make you super-dee-duper-scalable. Those attributes require good design, which isn't a given. However, a well-designed "monolithic" system can be these things as well. Neither approach is clearly superior, there are definite tradeoffs. This is akin to the whole "multi-threading doesn't always mean better, and can, in many situations, be worse."

Assuming you're someone wanting to actually ship a game in a reasonable amount of time, my only advice is to look at your game design docs and figure out the essentials. Make sure you really need this. As mentioned earlier in the thread, the MU* development attracts a lot of tinkerers and CS students, and we can find ourselves over-engineering things quickly.

Though, if you're just here to play and don't care if you ever open to the public, distribute yourself all night long.
17 Jan, 2013, Runter wrote in the 44th comment:
Votes: 0
Distributed systems are harder to maintain in my view only when they're highly coupled.

But when they're highly coupled…

1. It has negative synergy. The parts become more complex than their sum. And because of this, and because of their interdependance it becomes…

2. harder to write tests for. Granted, most mud developers don't write tests, and ..

3. increasing the reliance on tests is more difficult as a discipline. Unfortunately tests in a distributed system is very important for identifying problems with ..

4. consistency and failures across different components because of edge cases.

5. The more distributed and fragmented your system becomes, the more it depends on a deployment order and everything being in a certain state.

6. Figuring out the actual cause of failure across many services isn't straight forward after it falls apart as it was when you put it together. It can result in more down time over a long term.

Again, I don't actually see a problem with well developed distributed systems in terms of adding to maintainability or complexity when done thoughtfully.
But then again, I don't really see the point for most muds, either. I think it's not the "rope bridge" solution. It's more like building a suspension bridge.
17 Jan, 2013, Rarva.Riendf wrote in the 45th comment:
Votes: 0
I am also thinking: are muds that tied to their engines to begin with.
Do you really want to build a an engine from scratch to provide the game.
Can you not prototype it with an existing codebase, look if you can get players out of it, and then MAYBE look for a better modular over the top engine so you can expand.
It may sound as a waste of time at first, needing to port a gameplay to another engine, but if you dont have any players to begin with, why care about having an engine that cannot support thousands of players.
I think the engine are not really the problems to provide a mud people want to play to begin with. You can still swap it afterwards. I seems to remember that Aardwolf did it without that much of a problem.
There is more work in designing and tuning the gameplay than in implementing it.
17 Jan, 2013, Kelvin wrote in the 46th comment:
Votes: 0
I know there's an established game doing that right now, from Muck or Moo to Evennia, I think. There is some burden, as Rarva mentioned, but they've said that now that they know what they want, the second go around is going really well.
17 Jan, 2013, Idealiad wrote in the 47th comment:
Votes: 0
I think we go a little overboard with these 'opening a game' vs. 'architect astronaut' dichotomies.

I'll go out on a limb and propose that if you accept that the majority of opening a mud is the content and game systems, the actual architecture of your game will not matter that much in the end. To use an analogy from my profession, people tend to think of a house's frame as a major phase in building a house. But in reality it's only 5-10% of the overall process.
17 Jan, 2013, Rarva.Riendf wrote in the 48th comment:
Votes: 0
Quote
the actual architecture of your game will not matter that much in the end


I would say may instead of will. If your gameaplay is room based it may be complicated to then change to a roomless one. So you should still have an idea of what engine may be the next solution. Prototyping does not mean not caring about how you will do it next, it is also a way to check the validity of a solution.
And I think it is related to the subject. People forget than in the end the player do not give a single dam about how it works.
It is like in most open source project. They code the fun things, but when it comes to do the mundane stuff that actually matters to people, everyone leaves.
17 Jan, 2013, Tyche wrote in the 49th comment:
Votes: 0
A good example of a distributed system is a mud using a relational database server, like MySQL, SQLServer, or DB2.
It is claimed by many that one can save much time and testing by using generic off the shelve storage solution like an RDMS.
In this case, wouldn't one ship a more stable product sooner, as opposed to designing, debugging and testing a home grown storage system?
17 Jan, 2013, Runter wrote in the 50th comment:
Votes: 0
Quote
In this case, wouldn't one ship a more stable product sooner, as opposed to designing, debugging and testing a home grown storage system?


In this case, yes.
17 Jan, 2013, Rarva.Riendf wrote in the 51st comment:
Votes: 0
Tyche said:
A good example of a distributed system is a mud using a relational database server, like MySQL, SQLServer, or DB2.
It is claimed by many that one can save much time and testing by using generic off the shelve storage solution like an RDMS.
In this case, wouldn't one ship a more stable product sooner, as opposed to designing, debugging and testing a home grown storage system?


I would not call a database something part of the mud 'distributed services'. More like the use of a standard library.
An external 'pathfinding' service is more like it. Or an external 'mud commnication services'. Something that is not part of any of the shelf service that you are not the maintainer to begin with.
17 Jan, 2013, Runter wrote in the 52nd comment:
Votes: 0
Okay, in the case of distributed pathfinding services, I think that's a completely reasonable service, and one likely to let you test pathfinding in isolation.
There's also a lot of useful reasons you'd want to expose the pathfinding service to other software you're building. Like maps on your webpage, for example.
17 Jan, 2013, Tyche wrote in the 53rd comment:
Votes: 0
Rarva.Riendf said:
Tyche said:
A good example of a distributed system is a mud using a relational database server, like MySQL, SQLServer, or DB2.

I would not call a database something part of the mud 'distributed services'. More like the use of a standard library.

I was very specific. I wouldn't call "a database" a distributed service unless it was.
For example SQLite, while being both a database and a relational one, is clearly not a distributed service.
One would probably save the same amount of time, developing, debugging and testing using either SQLite or DB2.
However, the fact that DB2 is distributed brings another advantage to rapid development if a game.
I could take a web tool like Rails or Django and have an OLC Web CRUD application online in about 10 minutes.
Builders could be building the game before I even wrote a line of mud code (presuming of course I'm taking
a data development approach to game design).
17 Jan, 2013, Rarva.Riendf wrote in the 54th comment:
Votes: 0
I don't understand why you make a difference between the database, they can all be accessed without the mud using them running.
17 Jan, 2013, Davion wrote in the 55th comment:
Votes: 0
Rarva.Riendf said:
I don't understand why you make a difference between the database, they can all be accessed without the mud using them running.


SQLite is self-contained and serverless, so I don't think so.
17 Jan, 2013, Rarva.Riendf wrote in the 56th comment:
Votes: 0
http://sqlitebrowser.sourceforge.net/

edit:Hmm nevermind I think I got the point. It is about how you can access and modify it in a concurrent manner.
17 Jan, 2013, Davion wrote in the 57th comment:
Votes: 0
3rd party apps are cheating :P
17 Jan, 2013, Rarva.Riendf wrote in the 58th comment:
Votes: 0
Pfff the database is already a third party app…..but yeah I understood why you don't call it a "service".
17 Jan, 2013, arendjr wrote in the 59th comment:
Votes: 0
Paperback said:
Interesting, but not very interested in digging too deep because I'm heading toward my own conclusions. Nice web terminal. I was disappointed to see no one was online.

Yeah, maybe I should be online there more often. But then again, it really is just a demo server so you can play around and see the code is actually working. Behind the scenes I'm actually working on a completely different type of game :)

But throughout this thread I seem to detect you have a strong preference towards distributed services. Read on if you want to know why that may not be so feasible after all…

(Btw, there was some discussion about the line between distributed and non-distributed. So I'll clarify my own terminology: I'll consider anything using multiple processes that have no shared memory to be distributed. The separate parts of a distributed system should be able to run on different machines, but don't have to.)

Idealiad said:
(…), the actual architecture of your game will not matter that much in the end. To use an analogy from my profession, people tend to think of a house's frame as a major phase in building a house. But in reality it's only 5-10% of the overall process.

It's interesting you bring up this analogy, so you should know that if the frame is rotten, or is not strong enough to support that third floor you want atop, you have a very serious problem. Of course the latter will not happen that much with houses, as they're built according to a mostly fixed design, yet software tends to keep evolving and you will need an architecture that will support that. It may indeed not be the majority of the work, but choosing/building the right architecture for your project is of utmost importance.

Tyche said:
A good example of a distributed system is a mud using a relational database server, like MySQL, SQLServer, or DB2.
It is claimed by many that one can save much time and testing by using generic off the shelve storage solution like an RDMS.
In this case, wouldn't one ship a more stable product sooner, as opposed to designing, debugging and testing a home grown storage system?

I will use databases to make an example about the importance of architecture, and a little tale why distributed is not always an advantage…

My engine does not use a database. This is one of the design decisions I made very early on, and the main reason for it is performance. I realize performance may sound like a rediculous argument in the land of text-based adventures. But just because the output is purely text-based does not mean the server may not be doing some heavy calculations. And scalability to large amounts of concurrent users will require high performance too.

You may actually compare it to a dedicated server for Quake III. The server doesn't need to have a GPU, it's not rendering anything. And yet it's still doing some heavy work in the form of collission detection. If anyone would suggest that Quake III should use a relational database for its data, they would obviously be called out as being insane. Everyone knows that will be a death penalty to your performance.

But if you're building a MUD which is room-based, and all action will always be confined to that single room, the overhead of a database will probably not be noticeable. Perhaps you have a shout command that will affect adjacent rooms, but nothing that cannot be solved using a few SQL queries. All is good and well.

This is not what I wanted.

I want someone standing behind the battlements on a high wall. He will have a clear view over the grasslands, and will see people approaching from afar. Except when they're on the back side of a hill. Except when there's fog. The engine will calculate whether there's line of sight. The engine will know the distance, and use it to determine whether you can identify the person, or even see whether is a human at all. The distance will determine if his arrows can reach the person.

I want someone walking on soft shoes that muffle his steps when he hears a conversation. He stops and hears the voices of a man and a woman and they're plotting to kill her husband. The sounds are coming from the little office around the corner. If only they had closed the door, he might not have heard them.

I want someone throwing a granade into a corridor. The corridor is tight and the pressure of the explosion is compressed into two directions. People get knocked off their feet. The sound of the blast will alarm everyone within hundreds of yards. Even outside a soft cracking sound is heard.

These are the things I can actually do with my system of propagating events. However the algorithms involved will often require access to hundreds of objects at once. When an event starts, you don't know in advance where it will end. It literally depends on things like doors or windows being open or closed, presence of fog, line of sight, etc.. This means you cannot prefetch the objects. If I would've used a database, it would result in hundreds or thousands of SQL queries. At this point, performance is down the drain.

Had I used a database for my project, my main distinctive feature would've been impossible to implement.
17 Jan, 2013, Rarva.Riendf wrote in the 60th comment:
Votes: 0
Quote
Had I used a database for my project, my main distinctive feature would've been impossible to implement.


Having a database does not mean you have to work with it all the time. Nor push everything into it in real time as well. I work totally in-memory, I occasionaly save stuff on 'some' events, I am pretty sure the filesystem-io is a lot worse than what a performance a database that could also work in memory most of the time could provide. (the loss in performance is not a bottleneck so I dont care)
40.0/204