13 Dec, 2012, arendjr wrote in the 1st comment:
Votes: 0
Hey all,

For anyone interested, I would like to mention after many months of refactorings and heavy lifting, my engine PlainText is going into beta. What I mean by this is that the amount of changes to the core engine are expected to slow down from this point, and focus will shift toward fixing bugs, doing high-level work like improving the map editor, and working toward my own game which I may announce at a later date when there's something more concrete to show :)

The main distinctive features of PlainText are:

- Game events that propagate through multiple rooms. Hear sounds and see visuals as they happen in nearby rooms. Sounds and visuals lose strength and become increasingly blurry over distance and we use a semi-realistic line-of-sight algorithm to determine what you can see and what not. Currently we are just scraping the surface with this, but already it creates a much more immersive, rich and lively game world.

- Extensibility is provided through JavaScript. Whether it's triggers or other methods for extending game objects, the combat system, session handling, or implementing commands, all can be done with nothing but JavaScript knowledge.

- HTML5 map editor makes life easy for builders. This is one of the areas that will see a lot of attention during the coming months.

- High-performance multi-threading C++ core, designed for minimal latency. There's no database involved. While this is a continuous effort, the goal is to be able to contain a game world with about 1,000,000 rooms in memory on a server with 4GB RAM, and to be able to handle potentially hundreds (at least) of concurrent users.

If anyone is interested in building a MUD using the PlainText engine, you might be interested in these resources:

Project page:
https://github.com/arendjr/PlainText

Documentation:
https://github.com/arendjr/PlainText/wik...

Forums:
https://groups.google.com/forum/?fromgro...
https://groups.google.com/forum/?fromgro...
https://groups.google.com/forum/?fromgro...

Demo server:
http://mud.yunocloud.com:8080/
(use port 4801 if you want to connect with telnet)

Cheers!
Arend jr.
14 Dec, 2012, Idealiad wrote in the 2nd comment:
Votes: 0
Cool! I've been following PT on Github and it's been good to see it coming along.
14 Dec, 2012, donky wrote in the 3rd comment:
Votes: 0
If you have a blog (or find the idea of making one appealing) where you make technical posts about development of this, or any other mud project you have, I'd be happy to add it to "planet mud-dev" should that be of interest to you.
17 Dec, 2012, arendjr wrote in the 4th comment:
Votes: 0
Hi Donky!

I just created a new blog, can you add this one to the planet for me? http://plaintext-mud.blogspot.com

It's just a simple and plain blogger page, but I do got some ideas for follow-up posts :)

Thanks!
Arend jr.
06 Jan, 2013, Telgar wrote in the 5th comment:
Votes: 0
Cool. And lol, I'm working on a similar project. The entire MUD is written in Javascript with a minimal outer loop to handle file, network I/O, etc. What Javascript engine did you decide to use?
06 Jan, 2013, arendjr wrote in the 6th comment:
Votes: 0
I'm using the JavaScript engine that's embedded in the QtScript engine, which I believe is the stock WebKit one (the same one Safari uses), but not a very current one anymore…

They have recently released Qt 5 which has a V8-based JavaScript engine included, which I hope to use in the future. Anyway, sticking to the engines Qt provides is a real time saver because they provide a pretty seamless bridge between C++ code and JavaScript.

Do you host your project somewhere? Maybe there's a possibility for sharing code between our engines :)
06 Jan, 2013, khyldes wrote in the 7th comment:
Votes: 0
Just out of curiosity, whats the stand out benefits of using PlainText instead of something like Coffeemud? Or even RanvierMUD (uses Node.js)?
07 Jan, 2013, Idealiad wrote in the 8th comment:
Votes: 0
I believe PT is more developed than Ranvier and has fewer assumptions and more flexible development than Coffee.
07 Jan, 2013, Telgar wrote in the 9th comment:
Votes: 0
My project isn't hosted yet, unfortunately. Still very alpha. High level bird's eye view:

Circle MUD ported to Javascript. Like everything is in Javascript, even telnet option negotiation. Full Unicode support, variable-width displays, and interactive / popup menus and distinct features. Game mechanics are completely separated from game state. Game state is completely maintained in Javascript. Game code is fully runtime reloadable; and due to separation of state, game objects remain unchanged over the reload, yet the behavior can change. End result: seemless bugfixing, almost entirely crashproof mud. Oh, we handle infinite loops too…

We might be able to share some of the game mechanics code (when it is written), but it also might pollute your project with the Circle MUD license.

As far as the Javascript engine, I am using SpiderMonkey-1.8.5 with a bunch of custom modifications to eliminate some of the bogus "features" of Javascript, such as implicit global variables and automatic semi-colon insertion. I also expanded the JSON parser to make it more lenient.

Oh, and to all those wondering why Javascript… because it is awesome for rapid development and when used properly, an excellent modern prototypal language with tons of inheritance options and lots of modular code available to use from excellent libraries, like Node.js and YUI. It offers advanced reflection features and elegant functional programming techniques like closures. Also, the engines available already do automatic garbage collection and JIT compilation, making it nearly as fast at runtime as compiled Java code. Plus, Javascript never crashes. Most C code muds crash. A lot. C++ based muds crash either more or less, depending on the capabilities of the programmer. Java doesn't crash, but can't be easily broken into modules and reloaded at runtime. Thus: Javascript.
07 Jan, 2013, Rarva.Riendf wrote in the 10th comment:
Votes: 0
Quote
Plus, Javascript never crashes. Most C code muds crash. A lot. C++ based muds crash either more or less, depending on the capabilities of the programmer. Java doesn't crash, but can't be easily broken into modules and reloaded at runtime. Thus: Javascript.


If you want to have a good argument against C and C++ for a mud just use one: Handling and Parsing string.

But saying it wont crash…your buggy javascript/java program will crash just as much once it had gobbled every memory the computer has because you did not manage your memory right.
07 Jan, 2013, Runter wrote in the 11th comment:
Votes: 0
Javascript is just a language. The implementation is important when determining if it should be able to crash in normal use. Web browsers (without bugs) don't crash from javascript. The web would be a scary place and nobody would have scripting enabled if that were the case. If he's sandboxing his javascript the individual scripts will halt, not the entire server, and hence the game won't crash. It's an important distinction and one that shouldn't be hand-waved away as not useful, but there's loads of languages that will crash significantly less than C with the same amount of carelessness. It's not exclusive to javascript.
07 Jan, 2013, Rarva.Riendf wrote in the 12th comment:
Votes: 0
I do not say that 'not crashing at the first mistake' is not nice to have, just saying that more likely it means 'less crashing' not 'never'. A memory exception can come at any time, and you will have a hard time recovering from that. Even if you managed to catch it.
07 Jan, 2013, arendjr wrote in the 13th comment:
Votes: 0
I agree JavaScript has a lot of niceties, including not bringing down the server for what would be a null pointer reference in C/C++ :) However, in my C++ code I use a custom reference-counted pointer type, that simply throws an exception should a null-reference occur. The rest of the code is exception-safe, so also there the risc of crashes is greatly reduced.

I use JavaScript a lot for the high-level code. Often I think, if someone else is going to use this engine, will he likely want to customize this piece of code or not? If the answer is yes, I will prefer to write it in JavaScript. If the answer is no, I prefer to write it in C++. From this point of view I would encourage anyone who wishes to use PlainText to fiddle with the C++ code as little as possible. I hope this will help to avoid too much divergence between PlainText-based games in the future.

I maintain all game state in C++, including a separate thread that syncs it too disk as soon as it can without blocking the game thread. I also have a "reload-scripts" command that will reload all JavaScript code, allowing me to apply patches without disrupting game state or client connections.

Telgar wrote:
Quote
I also expanded the JSON parser to make it more lenient.

I can understand the removal of bogus features (though I'd say a lint solution would've been fine), but this last bit got me a bit concerned? Why would you want this? In effect you're making "your" JSON incompatible with everybody else's JSON.

khyldes wrote:
Quote
Just out of curiosity, whats the stand out benefits of using PlainText instead of something like Coffeemud? Or even RanvierMUD (uses Node.js)?

Compared to CoffeeMUD, the simple answer would be: The JavaScript engine doesn't suck. Personally I also think it's a bit confusing that CoffeeMUD appears to have JavaScript support as well as its own custom (very limited) scripting language. But let's focus on the JavaScript bits.

If you want to pass a string from JavaScript to Java in CoffeeMUD, you have to do this:
var javascriptstring=' this is a javascript string ';
var javastring=toJavaString(javascriptstring);

In PlainText, no explicit conversion is necessary to convert strings from JavaScript to C++. It just happens automagically when a C++ method is invoked.

Also, no standard JavaScript utilities like the Math class are available. In CoffeeMUD you need to do this to use the Math.pow() method for example:
var lib=Packages.com.planet_ink.coffee_mud.core.CMLib;
var value=lib.math().pow(4,2);

In PlainText (as well as every webbrowser out there), you can simply do this:
var value = Math.pow(4, 2);


Properties in PlainText behave as real JavaScript properties (even when they're defined in C++), rather than accessing the Java getters and setters. Compare this CoffeeMUD JavaScript code:
function newInstance()
{
var lemm=this.super$newInstance();
lemm.setName("a generic lemming");
lemm.setDisplayText("a generic lemming is waiting to commit suicide");
return lemm;
}

To the equivalent constructor you would write in PlainText:
function Lemming() {
this.name = "a generic lemming";
this.displayText = "a generic lemming is waiting to commit suicide";
}

I have a bunch of examples of JavaScript usage in PlainText in our wiki: https://github.com/arendjr/PlainText/wik... (check the Triggers, Commands, and Game Objects sections)


Finally, the event system (propagating to nearby rooms, with decreasing strength using semi-realistic line-of-sight and audio algorithms - this part is all C++ for performance), and the HTML5 map editor (screenshots: https://github.com/arendjr/PlainText/wik...) are the main features for which someone would want to try PlainText, I believe :)
07 Jan, 2013, quixadhal wrote in the 14th comment:
Votes: 0
Rarva.Riendf said:
I do not say that 'not crashing at the first mistake' is not nice to have, just saying that more likely it means 'less crashing' not 'never'. A memory exception can come at any time, and you will have a hard time recovering from that. Even if you managed to catch it.


Actually, no.

A memory exception (as in, you accessing memory you don't own) can't occur in a language which doesn't allow you to directly access memory addresses (unless there's a bug in that language implmenetation itself). You can write bad lpc/perl/python/ruby code all day long and you won't get a seg fault or bus error unless you find a way outside the sandbox (IE: call a module written in C that works around the rules).

If you mean "running out of memory entirely"… that depends on the language implementation and your OS. The language sandbox can easily watch memory availability and simply stop you from allocating more before you "run out". In that case, whatever thread is currently running will die, but not necessarily the entire program. In fact, you could even try suspending the thread, doing garbage collection, and seeing if it can continue before killing it off. Up to the language implementation.

Telgar said:
I also expanded the JSON parser to make it more lenient.


Why would you do this? JSON is already about as lenient as you could possibly imagine a data serialization protocol being… and now your JSON data can't be read by a standard JSON implementation. So, effectively, you've locked everyone out of being able to use it to make their own custom clients, file parsers, or whatever.
07 Jan, 2013, Rarva.Riendf wrote in the 15th comment:
Votes: 0
Quote
A memory exception (as in, you accessing memory you don't own) can't occur in a language which doesn't allow you to directly access memory addresses


"once it had gobbled every memory the computer has because you did not manage your memory right"
Was indeed talking about out of memory exception Quix. I never said it was impossible to recover from it either, but if you happen to have one, because your program is never freeing a variable (adding stuff to a static list somewhere and never remove anything from it), recovering only means it will soon happen again. and again and again etc :)
08 Jan, 2013, Telgar wrote in the 16th comment:
Votes: 0
arendjr said:
I agree JavaScript has a lot of niceties, including not bringing down the server for what would be a null pointer reference in C/C++ :) However, in my C++ code I use a custom reference-counted pointer type, that simply throws an exception should a null-reference occur. The rest of the code is exception-safe, so also there the risc of crashes is greatly reduced.


Like I said, in C++, crash potential is more dependent on the skill of the programmer… ;)

arendjr said:
Telgar wrote:
Quote
I also expanded the JSON parser to make it more lenient.

I can understand the removal of bogus features (though I'd say a lint solution would've been fine), but this last bit got me a bit concerned? Why would you want this? In effect you're making "your" JSON incompatible with everybody else's JSON.


I tried JSLint, it's a pain to use an external tool though as part of the import process. Plus, I just wanted to hack on the interpreter and JIT engine a bit for fun. Think of it as "super" strict mode.

My JSON parser accepts a superset of JSON syntax, but outputs 100% perfect by the book JSON. So I'm not incompatible, I'm super-compatible. This means you can write scripts which are a little more lax about syntax (such as not forcing quotations on all object keys) for quick import tasks, pretty print human readable zone files and still import them back, etc. I also added a triple quote literal string, sort of like a heredoc, that makes it easy to write human readable, formatted text inline in JSON, which otherwise, is a real bitch. For any external exchange, there is always JSON.stringify, which works as intended. Still, I think the Mozilla guys would probably rip me a new one if they saw what I did.
08 Jan, 2013, Telgar wrote in the 17th comment:
Votes: 0
quixadhal said:
Telgar said:
I also expanded the JSON parser to make it more lenient.


Why would you do this? JSON is already about as lenient as you could possibly imagine a data serialization protocol being… and now your JSON data can't be read by a standard JSON implementation. So, effectively, you've locked everyone out of being able to use it to make their own custom clients, file parsers, or whatever.


Lenient in the import direction, especially regarding whitespace. Strict in the export direction. So you can do things like this (note triple quote embedded formatted strings), which is a lot more readable than standard JSON.

{
"name" : "Miramar-Lock 6",
"number" : 186,
"creator" : "Unknown",
"editors" : "Unknown",
"date" : "Unknown",
"lifespan" : 30,
"reset_mode" : 2,
"flags" : [ "RESTRICTED", "!TELEPORT" ],
"civilized" : false,
"completed" : false,
"rooms" : ,
"civilized" : false,
"completed" : false,
"rooms" : [
{
"vnum" : 186000,
"name" : "Avatar's Passage",
"description" :
"""
You are upon the wondrous boulevard named Avatar's Passage, immediately
outside the gates leading through the city wall to lock three. To the south
this incredible street stretches far beyond your sight, to pass eventually
into the seventh lock and through that to lock eleven. The traffic along
the widest and longest street in Miramar never slows down, there are
always people about going about their business no matter what time of day
or night. Here in the entertainement lock, which spreads out to the south,
the street is usually full of drunk tavern patrons and the guard patrols
who keep them in line. You may leave north or south.
""",
08 Jan, 2013, arendjr wrote in the 18th comment:
Votes: 0
Okay, I understand the use case now… but still it seems a bit awkward.

If a builder comes to your MUD, would you recommend them editing these JSON files? I can understand it's a bit more convenient for yourself, but it does not seem like a solution you'd want to keep in the long run. Why not provide a decent property editor or more advanced builder interface? In the end the JSON files should be just data, and are not supposed to be touched by hand, nor even be looked at by the naked eye :)

Though yeah, I agree splitting multiple properties over multiple lines and keeping things a bit human-readable is still a good idea (I'm using JSON for data storage too, and doing exactly this makes the files play a bit nicer with version control).
08 Jan, 2013, quixadhal wrote in the 19th comment:
Votes: 0
First of all, JSON isn't meant to be a human data protocol, it's mean to serialize and deserialize data in a clean and efficient way. :)

Nobody in their right mind would be editing JSON data directly. If you have the object in code, you edit the object and re-serialize it. If you have the object on disk, you use an editor which reads in JSON and provides you with the object data to edit, then re-serializes it as it saves it back out. The end user should never, under any circumstances, be touching the JSON data directly.

That's the point.

Using industry standards means you can use anybody's JSON-compliant editor to work with the data and *NOT* have to worry about getting the format wrong when saving it. It also means anybody can easily build a "world editor" that reads in your JSON data files with about 3 lines of code. Those are good things.
08 Jan, 2013, Twisol wrote in the 20th comment:
Votes: 0
quixadhal said:
First of all, JSON isn't meant to be a human data protocol, it's mean to serialize and deserialize data in a clean and efficient way. :)


Douglass said:
JSON (JavaScript Object Notation) is a lightweight data-interchange format. It is easy for humans to read and write. It is easy for machines to parse and generate. It is based on a subset of the JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format that is completely language independent but uses conventions that are familiar to programmers of the C-family of languages, including C, C++, C#, Java, JavaScript, Perl, Python, and many others. These properties make JSON an ideal data-interchange language.


I agree that the JSON format shouldn't be modified, but it's not really a bad idea to edit JSON directly. Sublime Text 2 uses JSON for its config files; Node.js uses JSON for package metadata, and its require() can even parse JSON files directly for you. If you really didn't want human-readability, you could just use BSON or MessagePack.
0.0/44