01 May, 2013, plamzi wrote in the 1st comment:
Votes: 0
So, I brought myself up to speed on the two node.js codebases I know of: nMUDand and RanvierMUD.Unfortunately, the situation hasn't changed much in 6 months. RanvierMUD seems to be a little further on but is going really slow - at that pace, it will take a decade. nMUD is very basic and hasn't made progress in a year, probably ever since the initial burst.

Looking at the code, I was also struck by the fact that the basic approach of both codebases, heavily steeped in nesting and callbacks and dynamic function generation, generously sprinkled with event emitters even where there's no real need, makes for code that's pretty inaccessible to people who are fairly new to JavaScript and/or node.js.

I did a little experiment last day and a half to see if I can write something less opaque, that allows for dynamic game logic updates, and also something that can load and save its data in MySQL. I'm now able to walk around in the Bedlam world using this custom server, so I'm positive it can be done in code that doesn't make you want to tear out your eyes out of their sockets.

I'm wondering if there's anyone else out there who shares my general sense that it would be nice to have a liberally licensed, accessibly-written node.js codebase. My plate is full so I can't solo that kind of project, but I can help move it along. The world doesn't need another MUD codebase, that's for sure, but maybe there's enough interest out there in escaping various licensing restrictions, and in having something that combines the best of the old procedural with the best of the new oo & event-based design patterns.

Now I know some of you are already typing replies urging me to remove the dependency on SQL :) But even if this becomes a proper custom codebase project, I will not be interested in any other means to save state. This is 2013, and even 2-page websites about the family cat make use of an SQL database. The project I would like to be involved in will leverage queries in every way it can to make things easier.

Anyway, just a feeler / discussion-sparker.
02 May, 2013, Idealiad wrote in the 2nd comment:
Votes: 0
Why the focus on node specifically? If you're wanting Javascript PlainText was looking nice; though I think development has slowed recently it was pretty far along. I don't think it would play nice with your SQL though, so there you go :).

I think your experiment is a good one (writing a simple server against rich content, like your mud). From looking at a lot of bases it sure does seem like most of the code is overly complicated. Then again that's probably true of most programs.
02 May, 2013, Runter wrote in the 3rd comment:
Votes: 0
Not sure plaintext is the same thing. It's the difference in embedding javascript for scripting in a C core, or using javascript as the core of your engine.

Basically if you want to use node.js you should do so with the following in mind, in addition to the normal javascript caveats:

1. It's got a big community around it with tools that let you install it and run it in a multitude of places using packaging.
2. It is opinionated that you should be using certain parallelism mechanisms. Some people are going to balk at it because it can produce code that may be difficult to read and maintain if not carefully considered. Also it's easy to accidentally write code that isn't node.js friendly without realizing it.
3. It's "faster" than most modern language implementations using V8.
02 May, 2013, plamzi wrote in the 4th comment:
Votes: 0
Runter said:
Not sure plaintext is the same thing. It's the difference in embedding javascript for scripting in a C core, or using javascript as the core of your engine.


Yes, that's about right. PlainText MUD is in C++, and though it seems to have a more capable interpreter (description says you can write your commands in JS), it is not at all the same beast as something written in node.js. In the latter, there will be 0 need for any interpreter code because all of the code is already interpreted. So, you get full entity scripting capabilities "for free".

Runter said:
2. It is opinionated that you should be using certain parallelism mechanisms. Some people are going to balk at it because it can produce code that may be difficult to read and maintain if not carefully considered. Also it's easy to accidentally write code that isn't node.js friendly without realizing it.


This being one of the main problems I have with both node.js MUD projects that I looked at. If the goal is to create a modern-day alternative to, say, tbaMUD, catering to hobbyist coders who don't want to have to learn C, then you really have to stop yourself from showing off how 'metaphysical' you can get.

Anyway, this is just a PoC at this point, and I'm sure everyone's plate here is just as full as mine. I can probably use much of the code towards my next project, and I also may be tempted one day to write a different game (maybe something PK-centered) sitting on top of the same world. There's a lot to love in node.js.
12 May, 2013, quixadhal wrote in the 5th comment:
Votes: 0
plamzi said:
Yes, that's about right. PlainText MUD is in C++, and though it seems to have a more capable interpreter (description says you can write your commands in JS), it is not at all the same beast as something written in node.js. In the latter, there will be 0 need for any interpreter code because all of the code is already interpreted. So, you get full entity scripting capabilities "for free".


Well, yes and no. You could write a mud in any interpreted language and still want to embed another (possibly the same) interpreter in it. If you write your "script" code in the mainline driver code, you still have the issues of a single error crashing entire systems or the entire driver. Since we all know MUD's tend to have tightly coupled objects that don't lend themselves very well to being parallelized, this means you can't rely on node.js's mechanism to use threads for isolation – unless, of course, you want to write tons of deadlock code, or enjoy unpredictable results.

I suppose this matters less these days, since most MUD's tend to be one man shows, but should you become popular and get a team of builders, it's nice to know everything they script is isolated so it can only crash instances of what they build, not whole systems.
12 May, 2013, plamzi wrote in the 6th comment:
Votes: 0
quixadhal said:
plamzi said:
Yes, that's about right. PlainText MUD is in C++, and though it seems to have a more capable interpreter (description says you can write your commands in JS), it is not at all the same beast as something written in node.js. In the latter, there will be 0 need for any interpreter code because all of the code is already interpreted. So, you get full entity scripting capabilities "for free".


You could write a mud in any interpreted language and still want to embed another (possibly the same) interpreter in it. If you write your "script" code in the mainline driver code, you still have the issues of a single error crashing entire systems or the entire driver.


This is an academic exercise at this point, but as far as node.js goes, it's very easy to make sure that an addon script doesn't crash anything. You just wrap it in a try {} statement and catch any exceptions.

And when you're writing the minimal code needed for in-game scripting, you can make sure that only certain objects are exposed for modification to such scripts. That gives you the same level of safety as any interpreter, without actually needing to write one.

It's not totally "free", of course, but very close.
12 May, 2013, quixadhal wrote in the 7th comment:
Votes: 0
So, does a try/catch pair prevent a script from corrupting data in other objects? Because, as I said, most MUDs tend to have highly coupled systems that interact with each other quite a bit.

It's not enough for it to prevent a "crash", it has to also make sure a runaway builder's script that's supposed to (for example) enchant all the weapons in the player's party doesn't enchant all the weapons in the game.
12 May, 2013, plamzi wrote in the 8th comment:
Votes: 0
quixadhal said:
So, does a try/catch pair prevent a script from corrupting data in other objects? Because, as I said, most MUDs tend to have highly coupled systems that interact with each other quite a bit.

It's not enough for it to prevent a "crash", it has to also make sure a runaway builder's script that's supposed to (for example) enchant all the weapons in the player's party doesn't enchant all the weapons in the game.


My post already addressed this. You have complete control over what objects and what functions would be visible to these in-game scripts because individual node.js files don't share a scope by default. The file that loads these in-game scripts will explicitly hand over any references. So you don't have to hand over an object containing all weapons in game. If the scripts really need just "read-only" access, then you can hand over copies of objects such as the party/its members/members' objects that you throw away afterwards. Or you can have some simple regex functions removing anything from these functions that you think is unsafe.

I see zero need to write an interpreter, though anyone can feel free to disagree. I would personally rather have powerful, somewhat unsafe, scripting that needs to be debugged properly, than dynamic, limited, idiot-proof scripting. Though it's easy enough to have both, without having to write an interpreter.
11 Feb, 2014, plamzi wrote in the 9th comment:
Votes: 0
Quick update:

A couple of weeks ago, I got fired up and made a lot of progress on this project. Most of the basics are in place, and the code is now slightly ahead of the two other node.js projects I know of, which seem to be (regrettably) stalled.

One of the things that keep my enthusiasm going is to try and achieve near-full persistence while mastering an ORM. The end goal is to have harvestable vegetation, player constructions & improvements, and more or less complete state preservation of it all even if server crashes.

I'm also experimenting with a text-based UI that will use (and maybe even require) Unicode to achieve better information density and visual organization.

On the "for the heck of it" front, I added an NPC proc that can google things.

If you want to stop by, assuming that user/char creation is not broken at the time, the best way to do it is to click the image below.

22 Mar, 2014, Paladine wrote in the 10th comment:
Votes: 0
Hi there. This is a very interesting thread and I've been playing with Node and ranviermud a bit as well.

Plamzi, I tried clicking the picture to take a look at your progress, but the server appears to be down. Also, I was curious whether you were working on your MUD in an open source context - I'd love to see your approach.

As an old-timer who modified a lot of DikuMUD code (C) back in the day, I'd love to play a part in bringing MUD to Javascript, and I believe it's an excellent way to learn Node.
22 Mar, 2014, plamzi wrote in the 11th comment:
Votes: 0
Hi,

Server's up now (for a while, I was only bringing it up while working on it). Feel free to look around. You would see, for example, the graphical map, which is not shown on the above screenshot.

At this point, I'm much more interested in rolling out a full-featured game than yet another unfinished barebone "codebase". So there's no short- or medium-term plan to open the source. Also, it's already very likely that I'll end up with a game that will require a custom client. I'm thinking of one hybrid client and one all-graphical, with a lot of code re-use from my existing web-based apps. The graphical app is probably not going to look and feel like a MUD.

I haven't really given any thought to collaboration on this. Maybe if I found a "soulmate".
24 Mar, 2014, Chaos wrote in the 12th comment:
Votes: 0
It seems kinda self-defeating to me to use MySQL as your persistence layer for a Node stack when Mongo and Couch basically speak JavaScript natively. Just sayin'.
24 Mar, 2014, plamzi wrote in the 13th comment:
Votes: 0
Chaos said:
It seems kinda self-defeating to me to use MySQL as your persistence layer for a Node stack when Mongo and Couch basically speak JavaScript natively. Just sayin'.


Not sure I follow. The ORM I use seems to be at least as mature as node mongoose, and by sticking to SQL I am able to build pretty quickly without coding any specialized world building tools. At some stage, I can point a website to the same database, interface a bunch of other things I've coded over the years. So I don't feel too self-defeated. Just saying'.
25 Mar, 2014, Chaos wrote in the 14th comment:
Votes: 0
plamzi said:
Not sure I follow. The ORM I use seems to be at least as mature as node mongoose, and by sticking to SQL I am able to build pretty quickly without coding any specialized world building tools. At some stage, I can point a website to the same database, interface a bunch of other things I've coded over the years. So I don't feel too self-defeated. Just saying'.


Seems awfully handy to have the same data format in your program code and your persistence layer, not have to work around remapping of not-directly-compatible types, not have to update a schema to add fields. I dunno. I don't have a stake in proselytizing for the stuff, just seemed odd to see a new project going with MySQL under Node.
26 Mar, 2014, plamzi wrote in the 15th comment:
Votes: 0
Chaos said:
Seems awfully handy to have the same data format in your program code and your persistence layer, not have to work around remapping of not-directly-compatible types, not have to update a schema to add fields. I dunno.


This is exactly what an ORM does. I use node-sequelize. Right now, it supports 3 dialects, and NoSQL databases are not among the ones supported. But nothing stops them from adding support for MongoDB, for example, in the future.

When you use an ORM to achieve persistence, your server is basically agnostic to the exact type of storage being used. It can be virtually anything. You can switch relatively painlessly from one supported storage method to another, if you ever need to.

I haven't used any NoSQL databases yet, but from I've read they have one thing in common in that they limit the ways to manipulate the data directly. That's the main reason I haven't looked beyond my standalone MySQL server. I like being able to create entities, and correct any issues that can be corrected via one-off queries, directly in the database. It would be a major pain for me to give that up.
27 Mar, 2014, Chaos wrote in the 16th comment:
Votes: 0
plamzi said:
This is exactly what an ORM does. I use node-sequelize. Right now, it supports 3 dialects, and NoSQL databases are not among the ones supported. But nothing stops them from adding support for MongoDB, for example, in the future.


Heh. I'm one of those horrid people who habitually writes ORMs. One in Perl, two in PHP, one in LPC. I find them to be something of an inherently leaky abstraction, which is probably why the idea of working natively close to the persistence layer seems exciting to me. If you're happy with yours, certainly that's what counts.
19 Aug, 2014, plamzi wrote in the 17th comment:
Votes: 0
I've been making steady progress in this project, even though it's not my main ATM, and having lots of fun. And in the light of some recent thinking and events, I've decided to release an open source version of the Havoc codebase whenever I feel that it's a relatively full-featured offering on par with solid modern codebases like Evennia. To this effect, I've started refactoring and introducing some plugin flexibility.

Part of my thinking is that this project seems to be the furthest ahead at this time in the node.js field. nMUD and RanvierMUD development seems stalled or dead. I came across https://github.com/MoreOutput/RockMUD, which seems active, but is going to take ages at this rate. In the meantime, it kind of sucks that new coders coming to MUDs don't have a serious option written in JavaScript, a language that many know from web development.

At this time, I want to take the temperature of any folks out there who may be interested in contributing towards an open source release. You will find some details about the project in this thread and this latest post, and for the rest you can look me up on Bedlam or the Havoc test port (see sig).

If your interest is piqued, some things you may want to know right off the bat:

* Unlike most other node.js codebases, Havoc is going to use/require a database, and leverage an ORM (http://sequelizejs.com/). I auditioned mongo / mongoose, but decided it's not as mature and as easy to work with for what I have in mind.

* While Havoc is completely async and custom, there is a detectable CircleMUD / DikuMUD influence in the naming and some of the feature design, to the point that if you have such a background, you may find things easier to follow.

* This is not going to be yet another hastily written barebone codebase. Features like combat, class / skill system, quest system, and even crafting should / will be available from the start. There's also a number of fancy things that I'd like to have under and over the hood: near-full persistence, building tools, a sleek web-based client powered by the Mud Portal web app.

* The exact terms of the open source license are open for discussion. The only thing that's not open to discussion is that I want to release a version free for non-commercial use. Beyond that, I'm open to ideas about commercial licensing down the line, integrating payment support, etc.

* A lot of work has already been done. Enough to where you can take a look and quickly decide whether you feel like hopping on board.
19 Aug, 2014, Kelvin wrote in the 18th comment:
Votes: 0
Honestly, if it isn't a permissive license like BSD/MIT, you may find a really hard time getting any kind of measurable adoption with a new codebase. The deck is already stacked against new general-purpose codebases reaching critical mass and any significant kind of adoption.

Evennia started with a modified Artistic License that had no commercial limitations, but even that was a big sticking point for some. Re-licensing under BSD has made licensing a complete non-issue, and removed another barrier to those considering the codebase.

A new codebase has to push against the smothering weight of the Diku/Tiny legacies. Even if you "feel" similar to an existing codebase, you probably won't resemble Diku/Tiny under the hood, and you won't have the benefit of all of those mailing list posts and snippets that are floating around for your older alternatives. It's a substantial barrier to overcome, so resist the temptation get too stiff with the license, if you want people to actually use Havoc.
19 Aug, 2014, plamzi wrote in the 19th comment:
Votes: 0
Food for thought, thanks, Kelvin.

Right now, my main motivations are to have fun and to crank out something professional that I can add to my online portfolio. But I also don't want to be taken for a ride down the line. That said, I'm probably going to be OK with BSD/MIT on the codebase because I can always decide to develop some commercially oriented plugins later.

As for how "general purpose" this will end up being, I'm not sure. I know I don't want it to be too general. For example, I'm going to drop support for simple telnet so I can bake in things that lend themselves to a better web-based and mobile client experience. I also want to have a set of OOB features that match those of a normal playable game, just made modular.

In the longer run, I'd like to evolve this into an engine for online social games with less graphics and more depth.
24 Aug, 2014, plamzi wrote in the 20th comment:
Votes: 0
I saw some people stop by while character creation was broken due to refactoring in progress. Feel free to try again.

Lots of progress to report:

* Implemented a component / plugin hierarchy. All major features are now components that can be decoupled and replaced (even the world). Plugins extend components. Now using the built-in node.js event framework (sparingly) to achieve high modularity. Also, localization strings can be registered by both components and plugins – I expect it to be more convenient than adding separate files or modifying the basic language file.

* MXP is going to be all over the default components, just like extended Unicode icons, 256 colors, and GMCP data feeds. I'll probably add some basic stripping functions for people who wish to support dumber clients, but they will also need to do considerable manual scrubbing. On the bright side, people looking ahead will have a powerful web client via the Mud Portal as soon as they get their server up (and players will never need to learn most of the basic commands because they'll all be click-able).

* Code allows for runtime code changes almost everywhere, an ability restricted to your dev mode by default. This, while still taking advantage of node.js module caching in production. The built-in components will also update in-game instances that depend on them. For example, you can add commands, mob procs, even internal object methods, and your in-game objects will be automatically modified without the need to reboot. This is different / better than a hot boot because it will preserve the game state.

* Game features already exceed those that most codebases ship with: 6K grid-based world map, fully persistent mobiles and items with scripting, combat. Shops are nearly done, and the same code will handle PC shops, including the ability to purchase items from offline players.

Some things that I've yet to tackle:

* Movement from one map / area to another.

* A class component that grants special attacks (spells, skills) and probably special behaviors for NPCs based on class.

* Extend item affects, figure out how best to add item affects modifying combat, and then add a crafting plugin.

* Quest component. This is going to be tricky to do in a modular way because it will have to tie into everything else.

* Help system.
Random Picks
0.0/76