I was an admin (wiz) on various MUDs and MUSHs many, many years ago, and of course an avid user. The mix of programming, creativity, and camaraderie was sometimes very special. Maybe my recollections are clouded by nostalgia, but it sometimes felt like a hacker fantasy, coding, role-playing, and working together for good (fun). I wish I could recapture that feeling, I wish there were time for it, and I wish there were some way it would do good in real life.
I can't contribute anything directly about this bot, but I'm glad to see MUDs are still being studied. I feel like I never saw the full potential of what they could do for society. Some of the social interactions were much more rewarding than anything I have experienced on so-called "social" media.
Agreed! I am quite nostalgic about my time in MUDs and MUCKs. I recently came across a dot-matrix realtime-printout of some shenanigans (complete with type-over when I hit backspace). Brought a smile to my face.
The realtime, collaborative, communal, asynchronous improvisation that could occur was so, so satisfying.
> The mix of programming, creativity, and camaraderie was sometimes very special. Maybe my recollections are clouded by nostalgia, but it sometimes felt like a hacker fantasy, coding, role-playing, and working together for good (fun).
I agree! I got into MUDs when I was 13-14 and they introduced me to good programming practices early on with things like CVS, checking patches in a group, and running dev environments for testing with various playtest groups.
The dev cycle was great too, with to-do lists based on long-term goals and player input, with coders/admins breaking up tasks for planning to get things done.
It's really hard to overstate how important that was in instilling good practices and a feel of "this is how things should be" in me as a kid, and it's definitely carried over to my professional life now, some 20 years later. I even wrote about it in my college entrance essays (something my mother mocked me for), but it was such a good experience that I don't regret it at all.
I actually found a split-off branch of a MUD I used to frequent/code for and after logging in and asking about people I remembered for a while, someone started a global in-MUD game -- one that /I'D/ made over a decade ago. That was an incredibly gratifying experience, knowing that some of my oldest, most amateur code was still out there and people were still getting some fun out of it. :)
Edit: If anyone out there was on some Wheel of Time MUDs, I was on The Weave/The True Source and As The Wheel Weaves.
If it were marketed correctly ("literary gaming" or something), I could see a modern variation of a MUD gaining some traction if it were browser based and styled up in way that's a little more accessible, with some other modern conveniences.
Kind of like how Discord and Slack are just a coat of contemporary Web-isms on top of the same old idea as IRC.
I feel the same way - I have a lot of great memories associated with those times, and some fantastic life and development skills picked up because of it (I wrote my first virtual memory subsystem for a mud to work around me not having enough ram to load the world). I feel very nostalgic about text based adventures, and really feel like a lot of gameplay is really missing the imagination and experiences that were able to be captured by such a "primitive" interface.
Well that's kinda cool. I didn't know there was a discord chat for mud coders. Also it appears there's a slack chat for mud coders as well https://mudcoders.com
Oh even cooler, there's a mud chat network so people can chat between muds: https://grapevine.haus (coded in elixir too!)
Very cool! I'm working on a browser game using threejs and websockets. Its progenitor was a MUD that I wrote that I never felt was good enough to publish. Joined the discord and all else. :)
(Side note, maybe this will hit google for some poor sap in the future. Blender 2.8's GLTF/GLB exporter doesn't respect the armature modifier. Bake your weights if you want your ground tentacle to wiggle in your browser. :( )
Doesn't look like this does anything clever/special; it just randomly spits a finite set of handwritten commands to the socket that the author's target MUD happens to accept.
Was hoping that this was something more like AFL for TCP clients, discovering all the commands the MUD supports, and through it, the entire state-space of the MUD's world-model.
How useful is this test tool to you? What bugs did you find or do you hope to find this way? How often and long do you run it?
I'm asking, because I guess, it probably takes ages to traverse some kind of dungeon. If there are special sequences, the tool will most likely never find them (like find key, open door, kill boss), right?
I've done some small games in my spare time, but Unit-Testing was either completely useless or way overkill. But I guess, the larger your game gets, the more important it will be.
But the the work involved is so huge, that I think it's not worth it for indy games or small studios. If you look at the test setup for AAA-Games, like League of Legends [1], the work involved is mind-blowing...
noric-bot has been extremely useful as a test tool, if a bit narrow due to just spamming random cmds. To your point, the bot in its present form can't automatically run a dungeon or verify edge cases.
A previous version of the server codebase was written in ruby[1]. The playable branch of that repo has a combat demo that's a bit fun, however the performance is so terrible that I shelved the whole codebase years ago.
As a long-term vision I'd like to launch an indie MMORPG that supports at least 1,000 players per synchronous, single-threaded server. It's an item/equipment focused game. Each player may have hundreds of items with a total of thousands of affects. noric-bot helps me stay on track with that goal.
What bugs did you find or do you hope to find this way?
The server is an actor-based "distributed system" using Akka. I only ever run it on one jvm but in theory it could be clustered. The bot helps find performance bottlenecks and actor-related edge cases.
The server runs at 4fps and Very Bad things happen if the 250ms frame time budget is routinely exceeded. The bots use a special password to spawn "fully loaded" player mobs with hundreds of items and ~1k affects. This helps me see bottlenecks like saving/persistence, I/O, Akka mailboxes growing, time spent processing player cmds vs moving the simulation forward naturally, etc.
Sometimes the bot will find logical bugs. This is usually in the context of assertions I've added that the bots will trigger.
I'll routinely write fake commands that bots will spam to execute scenarios that otherwise would be unreachable (if only due to lacking gameplay functionality at this early stage).
Often I'll just run the bots for fun and see how the game feels with a lot of other "players" running around :-)
Is your game project available publicly to play, and/or is it open-source? Have you ever participated in the MUD Coders Guild community? It's been mentioned elsewhere in the thread.
The author gushes over scala but completely neglects to mention scala.js :) (I sincerely hope he's seen it, since he seems to be a js dev). scala.js is right now the only way I use scala- after I dropped scala for backend.
The CoffeeMUD MUD engine is very feature-full and nice (IMHO). It is written in Java, and has a web interface for most activity. You can get more info here: http://www.coffeemud.org/ There is also a Discord server at https://discord.gg/HgDxtas...
Scala does have some interesting applications for stress testing. I personally think that this project could have benefitted from the Akka Streams library. Akka Streams allow you gloss over thread creation while focusing on scheduling events to send to a sink. Pretty handy when you want to quickly spin up a rudimentary stress test tool.
not quite related but ... any recommendation on a good open source mud? most of the projects I've tried have been very raw, or unmaintained. eg https://ranviermud.com/
Cool project, but why engage in language flame war on the project readme:
> I think Scala is the best mainstream language with a sophisticated type system. Sophisticated type systems are money in the bank. Going from TypeScript to Scala is like going from JavaScript to TypeScript.
Thanks for the feedback. I have updated the README to use less inflammatory language and be more specific that the comparison is just for the type system.
The new text is
For me, from a type system perspective,
going from TypeScript to Scala is like
going from JavaScript to TypeScript.
(I love TypeScript and write a lot of it!)
package mypackage
import shapeless._
import anorm._
import mything.MyObject._
import com.seriouscompany.Foo
object MyThing {
val a = new A()
}
What does A refer to? Where does it come from?
One of the 15 files in the anorm package? Does it come from one of the 40 files in the shapeless package? What about mything.MyObject and the dozen mixin traits that it has?
Alright, let me clone the repo, startup my 4GB IDE, wait 15 minutes for it to download JARs and index eveything and then I can get an answer to where `A` is defined.
Scala wildcard imports are very common in practice, but even if I eschew them, there still another 50 files in the mypackage package that could contain its definition.
---
The same thing can happen in TS with globals, but those are rather few.
Well, I bet it comes from either shapeless or anorm or mything.MyObject. Moreover, how is this different from literally any other programming language? Also, I would venture to guess that almost all programmers regardless of the language or editor/IDE they are using have some sort of jump to definition function they use all the time. At least with Scala I can actually see the source of the definition reliably, which is more than you can say about C or C++ (headers don't count).
JavaScript or TypeScript don't have the problem (except for globals, but those are usually few and far between).
Python doesn't have this problem (unless you use wildcard imports, which is often recommend against [1]).
Java does not have this problem, except for protected/internal classes which have only local use anyway (yes there are wildcard imports, but they are rather rare [2]).
Go has this problem for files in the same package, but not from other packages.
C and C++ are far from a hallmark of readability. Though there is at least a common C++ practice to at least always use the fully qualified name [3].
Ruby shares this issue.
---
What makes Scala worse is that wildcard imports are strongly encouraged by libraries and in very frequently found practice, for things such as implicits whose whole purpose is to not be explicitly named.
Plus in Scala, object, classes, fields, methods...all of these can be imported into the scope. So in practice this becomes a more common problem.
How can you say "_____ doesn't have this problem (unless you use wildcard imports" when all of the languages you listed allow wildcard imports? (Or just dump all their garbage symbols in a global namespace.)
Like I said, in practical terms, this turns out to be a much bigger issue for a random selection of Scala than a random selection of Java/TypeScript/Python.
Just like every language has an untyped/unsafe method of operation. But some languages use that sparingly; others have that for the whole language.
Implicits allow for a kind of flexibility and power that is absent from pretty much every other language. Allowing functions to implicitly introspect their caller’s context is incredibly useful. The only languages that can even half way do this kind of things without crazy dynamic introspection/reflection are those that support dynamically scopped variables (such as Common Lisp). And even that isn’t as powerful.
Not only that, accusing TypeScript of being "unsophisticated" is just dumb.
Unsound, inconsistent, overly complicated, poorly abstracted, improper paradigms.....any of those would be a more legitimate criticism than "unsophisticated".
Typescript is flawed, but it is a godsend compared to using straight JS. You can use it like Java until you can't. And then you are forced to muck around with JS hacks just to please the transpiler.
Usually that happens using generic types. They are almost completely worthless in Typescript, and have no analog whatsoever in JS. So you are mucking around just to please the transpiler but adding a type unsafe hack anyway in place of a generic argument.
Typescript should have just stuck with providing checks on type declarations. That's it. Stop adding features from Java/C# when they make no sense in JS.
I would pick another language in a heartbeat, given a choice.
TypeScript's type system is actually much more expressive than Java or C#'s. You can't express OR types (sum types) like `string | number` nicely in those languages. It's the main thing that made me hate statically typed languages until I tried Rust (which also lets you express this).
Huh? You would just overload the method then in another language. That is a lot safer than manually checking the argument type inside the method with the hack you proposed.
You're right if by "more expressive" you meant "not really safe at all". By using the types of hacks you proposed, you end up losing type information and safety guarantees. So why bother using Typescript in the first place then? Your example is the perfect argument against Typescript.
If you were referring to generic types, then there's no good reason to do that in the first place. Use a base type. Polymorphism 101. Anything else would be duck typing, and not safe.
There's no middle ground with type safety: it is either safe or not. And if there's a chance it's not, then you've lost and all of your efforts are pointless without resorting to manual checks.
And if you were somehow referring to C++ like templating (unlikely), then Typescript doesn't support that anyway.
I think the author was trying to point out that Scala has type system features, like Higher-kinded types, which (although very useful in practice IMHO) are non-existent in other mainstream languages, including TypeScript.
I think that's a legitimate and, most importantly, factually correct point to make.
apply to the current stable version of Scala as well. You'd be comparing Typescript as it is in production right now to a best case scenario of where Scala could end up in a couple years.
> Not only that, accusing TypeScript of being "unsophisticated" is just dumb.
Probably, but the thing you are doing doesn't accuse TypeScript of being unsophisticated but of having an unsophisticated type system (these are as different as describing a person as being short is different from describing them as having short hair.) And, yeah, a type system that lacks soundness, lacks consistency, is overly complicated and poorly abstracted, and uses improper paradigms can fairly and succinctly be described as unsophisticated compared to one that does not have those shortcomings; the descriptions you point to may be more specific, but are not more legitimate, nor are they more appropriate when the context isn't a detailed dissection of the language.
> Sophisticated type systems are money in the bank.
You better have money in the bank to allow for all the refactoring you will be doing once you realize your data model needs to change in unforeseen ways ;)
Awesome! I'm going to have to check that out. I'm doing a human stress test on my mud project, Enceladus right now! There's over 25+ people in so far. It's the worlds first realtime crypto RPG, as in you can find ethereum in the game. Come help us test it!!
This is a pretty blatant advertisement, part of a larger pattern of what would be charitably called "aggressive self-promotion", and in fairly poor taste IMO. This comment had close to nothing to do with the subject of the parent post except the tenuous connection via the "MUD" keyword.
You know, I came here because of that keyword and I, of course, appreciate MUD-related posts, including GP's. You may have come for "Scala" or "stress-testing", causing you to perceive the connection via the "MUD" keyword as weak. From my perspective, however, the connection is as wide as heavens and earth, and stronger than what's needed for a space elevator. I spent a good part of my youth playing, writing, programming, and hacking MUDs, and now I'm glad to have learned that there are still MUDs in active development, even if I probably won't have the time to enjoy it.
In short: self-promotion isn't bad, the GP post is related to the article, and frankly there's no need for your input here - the "poor taste" comment was unwarranted and... in poor taste itself.
ah man, you're right. I was just really excited is all, because lots of people started coming into the MUD chat rooms, and I'm doing a playtest today (the old school way), and I've been building this for nine months! and I'm not making any money off of it, actually mostly giving away eth. I forget that other people aren't going to be as excited about it as I am.
I just want everyone to come see what I'm building!
I can't contribute anything directly about this bot, but I'm glad to see MUDs are still being studied. I feel like I never saw the full potential of what they could do for society. Some of the social interactions were much more rewarding than anything I have experienced on so-called "social" media.