2020-11-22 04:10:01

Web interface: http://audio.servegame.com:8080/
Telnet interface audio.servegame.com

This is a very basic MUD where the users can create the content from within the game. I'll put it up on New Releases in a day or two, but I thought I'd pre-post here, in case anyone finds any glaring errors.

For years I've wanted to create a simple, minimal, extendable MUD engine like the old LambdaMOO. I tried to add user content creation into my audio games on Alexa, but the quality was never there to do true editing, and the castle building stuff I had was kind of constrained. With a text game I'm finally free to achieve this.

The core of the engine behind this has almost nothing to it. Just the idea of objects, that objects can be contained in objects, and verbs that can be attached to object classes. The Sandbox is a reference implementation that adds the concept of rooms, exits, players, simple items and containers. But any other sort of text adventure style interface could be built on top of it.

I just wanted to fly this simple implementation up the flagpole to see what interest level there was. The base code is in Java, as is the current implementation of The Sandbox. However, a more LambdaMOO implementation would be to have the extensions coded from within the platform itself. For example, to extend it so that you could add verbs to objects from within the game by adding scriptlets in Javascript, or possibly other JSR-223 scripting languages.

I'm contemplating things like the Sub War or Star Lanes game from Alexa to run off this engine. Or a space trading game that died before I got it to production on Alexa. Or even writing a text version of Among Us.

I'm interested in people's thoughts and opinions, both positive and negative.


Thumbs up +2

2020-11-22 04:52:02

Probably the most glaring thing is the fact that commands don't have common aliases which most MUDs tend to share, such as, 'l', for look, and exits aliased to either one or two letters, such as, 'n', 'u', or for non-cardinal directions, 'ne'.

There are also grammatical errors, like the lack of an article prepended to an object's name, and things like is/are not aligning with however many objects are in a room.

It is also not common to see yourself in a room's content / people listing unless there is a mirror or something that would cause you to see your own reflection. Even then, it would be more appropriate to have the player look at the mirror in order to see themselves.

But yeah, I think this is probably a better approach honestly. I get frustrated trying to play games on Alexa just because I feel trapped between not knowing how to do things or getting too much help when I already know what's expected and what I can say at any given point. Then the inevitable struggle with getting a command you *know* is correct to register. You spend more time fighting with it than chilling out and enjoying it. This isn't exclusive to your games, and I'm not trying to single you out or anything. Also, I had a game break itself by triggering Alexa when in the ending credits, it said something like, "thank you for playing this Alexa game". Well, Alexa got triggered, then the game looped back to the last action prompt and it became a perpetual cycle that I had to break by going over to it and hitting the mute button. Interestingly enough, it didn't happen in the beginning of the game, which leads me to wonder if there's a way to program it to know that the next utterance of Alexa should be ignored, and they just forgot to do it in the ending scene.

Wake me up when the world has unfucked itself
Is time really linear?
You can find me on discord: ironcross#8090, though I don't know why you'd want to.

Thumbs up +2

2020-11-22 05:17:19

Great feedback!

Many commands have aliases, but lacking L for look was a dumb oversight on my part.
Directions are different, since they aren't hard coded verbs, but depend on the name given to them. I had put that off because to support that I'd have to support aliases for all objects. (Directions are just an exit object.) But I accept your point that it is a problem for general consumption, and I'll add it to my must-have list.
I, likewise, put of ommiting yourself from the description, since it was difficult the way the code was structured. But usability always trumps programmatic difficulty, so on it goes.

Alexa activating itself at the end is a bug that's been noticed a few times. Amazon appear to consider it a low priority one, given how long it's been there.

It's funny, because I've spoken internationally about the need for audio assistant applications to make their functionality discoverable and to scale back their verbosity as the user masters the application. There is a LOT in Six Swords, for example, to do that. So that's a little disappointing to hear that even I can't get it right!

There is none of that at all of that in this game, so it probably will get tedious quickly. I'll start thinking about how to make it easy for in-game content creators to author that sort of scaled verbosity into what they make.

Thanks again. I've transcribed these into the issue tracker GitHub and I'll get on it.

Thumbs up

2020-11-22 06:11:04

If you're modelling things such that even exits are objects, expect scaling issues even for muds, primarily around memory usage but also potentially CPU as well if you push that viewpoint far enough.

My first thought is that I'm not sure what the point is, given that a million moo cores do everything you're saying this does and then some.  I think that you'll find that this community won't be overly interested, as it sounds like whatever needs you have are very specific to whatever it is you're hoping to build.  Those of us who are advanced enough to want something besides Moo don't typically want to create content in the game like that because it's not a scalable design, and not having the ability to roll back as you can with a git repo, or to merge, or etc. all quickly become massive issues.  I'm sure anyone who's played moos for any significant length of time has been around for at least one "oops, we broke it and can't roll back, excuse us while we patch it live" story.  I'm not really sure what original problem this is supposed to be solving.  I'm not saying there isn't one, just that you haven't told us what it is.

You need to be careful if you're going to expose an actual non-custom scripting language to untrusted users.  Sandboxing the language is fine, but you can't implement cooperative scheduling on top of it and a one thread per running script design will fall over quickly, which means that you can't bound execution time.  A malicious  player just has to while(1) and then the server goes down.  The only thing I know of offhand that deals with this that isn't a custom language built for it is lua, but that comes with the big caveat that you're actually bounding vm instructions and not time and there are still plenty of ways for someone to DOS it by just executing VM instructions that hammer the APIs you've provided to the script in ways that will block.

My Blog
Twitter: @camlorn38

2020-11-22 07:05:53

Good points, @camlorn.

Unlike LambdaMOO, objects are not required to be persisted in memory. They are only instantiated when needed, and discarded afterwards. I do have a cache for speed, but that can be managed within whatever the memory constraints are. The whole object persistence layer is abstracted behind an interface. Each object is described via a URI, and that URI contains which persistence store to use to retrieve it. For the reference model, there is a disk model for persistent objects, and a memory model for temporary ones. One reason for this is that some of my ideas (a Star Lanes port, or if I resurrect Six Thieves or Star Trade) have procedural generated landscapes. On feature people liked in Six Swords was that you could explore the entire islands of Ireland and Iceland in the game. This would allow for implementation of that (or infinite landscapes if completely generated) without overwhelming resources requirements.

It wouldn't be too hard to be able to checkpoint the whole world, for static rollback positions. But, yes, it gets a little trickier with subsections of the world and there is much I would re-implement to get things the way I want them, but I'm not up for re-implementing Git! That said, though, I'll think about the idea that you could point to a repository as the source for your scripts, instead of actually putting them in-line.

Right now there is no multi-threading. And, yes, you are entirely right that adding that would open the gate to a world of problems. Definitely one of those "approach with caution" sort of things.

I have a lot of ideas that I've accumulated since I started the audio games stuff, and I didn't want to just regurgitate them all into an endless post that no one would read. But I'm happy to go into more detail and you can correct me if there's something that does it already. I'll be the first to admit that I don't have exhaustive knowledge of everything that's out there.

The MUD cores I've seen out there seem pretty static and finite. I tend to gravitate towards writing open world type games with either vast or infinite landscapes. I like sandbox styles games because I want to give users more creative control, but that has a lot of the problems you mention.

I put a lot of work (and lines of code) into the back end of my Alexa games to cover the sort of things ironcross32 mentions. This kind of breaks down into two major areas: input and output.
On the input side, voice recognition is not an exact science. Alexa, as many people complain, doesn't always get exactly what you say, to say nothing of homonyms. There's a bunch of stuff I've done on the voice side to deal with that like fuzzy matching and phonetic matching. Right now, for example, I stuck into the Sandbox an analog of my late lamented pet cat Khol. Now, if this is being read out by a screen reader I don't think the user is going to be able to distinguish between Khol, Coal, Cole, or Kohl. The stupid regex matcher I have there right now isn't either. My understanding is that most MUD engines are still primarily geared toward sighted users, and don't do that sort of matching. I have the tools to make this better, and with my own platform I can add that in.
For output, on the voice side, I have stuff that lets you declare different parts of your output to be within certain verbosity levels. The system tracks how often you've heard things, and can scale it back as you become more familiar. All strings are externalized, nominally to allow for translation, which I could never afford, but more usefully it forces the coding to refer to everything by identifier. That allows for alternative text to be supplied and randomly delivered, decreasing the monotony of output. Similarly cross references and inclusion can be done that makes it easier to build up complex output.
Sort of between those two categories is discoverability. In my voice back end I can tag certain commands as having likely commands that are likely to be subsequently invoked. If the user hasn't been told about them before, then one of them is mentioned. Like the verbosity, this decays over time based on how often the user has heard the prompt and how often they have used the undiscovered command. This was critical is voice since long dumps of command options are just way too tedious when read out.

So, overall, I want the toolbox of stuff that I needed to have for voice available for text adventure type games. If the primary audience is people with screen readers, much of what I needed to do for voice would provide good usability there as well. I've already got all the code. I just have to move it over. If there are platforms that do much of this in an easy way, then I guess I don't need to.

Thumbs up

2020-11-22 14:25:34

as a developer I definitely have gotten used to using a versioning system like git as a safety net. the fact I can make experimental changes stress free, knowing I can get back to a sane version of my project with a single "git restore ."

but maybe some basic versioning wouldn't be too difficult to implement. and as long as areas could be sequestered in a way that version histories would be seperate, then it could work in that regard.

From reading about your ideas on handling input, output, and discoverability, I think you might have spent a little too much time in Alexa land. Alexa as a platform is probably the most limiting there is for games, even when compared to MUDs. I think you will find that a lot of the considerations for input and output that you have to deal with to make a game on Alexa bearable, don't apply once you are in a less limiting context.

for input, since user is typing instead of having their voice interpreted by a machine, the sort of auto correction isn't necessary. what you can do in the text game scenario is to just include various synonyms for vairous commands, which is commonplace. also possibly if the command isn't recognized, then game would give them a couple of commands that are close (if any).

in terms of output, the biggest problem with MUDs for VI gamers, is the inclusion of ASCII art, which is more a problem with game design than the engine itself. as for things that sound similar, I figure out which one is meant from the context and if I can't then I just spell it out. once you aren't in Alexa land and have a full-powered screen reader, then that kind of stuff isn't a concern.

discoverability is an interesting topic. I think there could be improvements to how that is achieved. generally, I think a good tutorial at the beginning of the game is the best thing. particularly introducing controls gradually, as they become relevant and the player has had some time to digest the other controls introduced so far. all non-audiogames do this and it is very effective and enjoyable way to learn the controls, but for whatever reason, audiogames still tend to just have you read a long doc explaining all the controls before playing, which really doesn't make for a great experience.

so, for me overall I think poor player experience in MUDs is mostly due to poor game design rather than the engine the MUD is built on not having enough features.

Thumbs up

2020-11-22 18:54:11

Hmm. I think I might need to throw something together to illustrate some of my points. In Star Lanes, for example, there is an expansive stellar landscape with the points named for medium sized cities on Earth. It's a nice, thematic thing, and it's a problem on voice because if you hear Cincinnati or Udaipur, you have a reasonable chances of speaking it back close to how you heard them. But it would be much more problematic to spell them exactly correctly.

And, yes, design of the user experience is what is of prime importance. But a system can encourage good design by making it easier.

I finished the bugs ironcross32 came up with. Let me see if I can port over one of these landscapes as another test case.

Thumbs up

2020-11-22 19:22:50

ok i am not 100 percent sure how to conect with mush client. i am kinda new to muds so sorry if theirs a place to ask or learn

Thumbs up

2020-11-22 20:53:02

You can solve the entire input problem by just supporting tab completion and telling us that you support tab completion.  Maybe I don't know how to spell something but it's not hard to guess that it starts with a specific letter or set of letters and tab.  I'm going to guess that you're sighted, and have found your way to writing games for blind people through some path.  The problems you think exist don't exist unless you're going to block us from reviewing the output to check the spelling of things.  You can go very far with soundex and "did you mean...".  Beyond that you get seriously diminishing returns.

There was a mud called Wayfar 1444, built on top of Moo. It was exactly what you're describing.  It ran fine without swapping things to disk, except that the coder who wrote it had zero programming experience and made all of his algorithms O(n^2) because he'd never heard of a tree, then it fell over (I use this example because most of this community misses that game, and it's the perfect example of what I mean about coding things poorly).  There's lots of other muds that did massive outworlds without swapping to disk: medievia, Materia Magica, Empiremud, all of which are still running.  People were doing what you wanted to do on servers from 20 years ago in lpmud which is definitely slower than Java.  I would politely suggest that if your first thought is "I can't run a big text world without being able to offload things to disk on demand", you're really considering this wrong.  Drop some of the genericity, for example inline exits into the room class, or even just say that areas are grids with tiles, and you will be able to scale the world as much as you want without having to solve these sorts of problems.  You can reasonably get 1000x1000 grids into memory without even being clever in the slightest, a bit of cleverness gets you easily to 10k square, and then you can solve the rest just by calling them "planets" and making each planet a different area or continent or what have you.  Just memoize your strings, you can get rooms down to (say) 100 bytes, lower if you weren't in Java or if you switch to an array of structs representation, then a 1k square of tiles is only 100mb and a 10k square of tiles is only 10gb.  Both of those fit on a server fine, and if your goal is make big grid-shaped worlds you can be even more clever than that.  But also, in a text world, no one will be going "wow, this 1k square is too small, I wish it were bigger", so just split it into zones, and save yourself the headache.

My point about git isn't that we need to use git, except that it kind of is.  Anyone with a lot of coding experience will avoid your engine like the plague if it can't easily solve the merge conflict problem.  You're re-inventing moo, which is fine, god knows we need a modern one.  But lesson one from moo is that this sort of design actually prevents you from having a test port, and lesson two is that this sort of design entirely prevents you from working on a team.  The road you're going down forces anyone coding content to code live against prod with no easy rollback and no easy way to collaborate without telling everyone else that you're coding on Mount Doom, don't touch it, and also god forbid that someone tries to play through the content while you're building/fixing it.  Anyone experienced understands this and starts hating Moo very much, so if you want to attract experienced people you need to solve it.

My Blog
Twitter: @camlorn38

2020-11-23 00:20:18

Tab completion is a very interesting idea. For fuzzy matching I'd have to span the entire possible input space anyway, and that would make tab completion possible as well.

Yes, I am sighted, and came into this via doing Alexa stuff. The only people who really played my more involved games were visually impaired, so I figured I might as well just focus on that. I do apologize for naive misunderstandings on my part, as I clearly don't have a native understanding of this space. And I thank you, or anyone else, for pointing out those naive misunderstandings. I'm also on the older side, and have been a software engineer my entire career. Business though, not games, so while I have no trouble coding difficult things, I can still make other naive game mistakes.

Professionally right now I'm team lead on a project that does have a full rollout hierarchy from local to development to test to sandbox to staging to production. So I get where you are going. You are right, it is a hard problem to solve with a pure moo where there is no real boundary between data and code. That does weaken the use case I was trying to demonstrate with The Sandbox concept. Unless I can think of a solution to make staged roll outs possible. But that's a hard one, so let me talk about some other use cases.

This use case assumes a basic deployment that does nothing except provide an environment. The users then have the ability, as gameplay, to create more gameplay. I like that a lot, coming from an very early very happy experience with LambdaMOO. But your language, and others here, more points to the idea of one or a small team of developers creating content, and releasing that for mostly static game play by the users.

So, looking at that use case, that's kind of what I've got at the core level. The lowest layer (the jo.audio.loci.core  project) is the very basic fundamental stuff. The root objects, verb structures, and the engine that evaluates a line of text against a position in that environment and matches it to a verb with direct object, preposition, and indirect object. The Sandbox is built on top of that (the
jo.audio.loci.sandbox project). In LambdaMOO terms, it's kind of the baseline code that most MOOs start with. But it's all in Java and only enables extensions through data. I've suggested making that layer extensible so that additional logic could be added via embedded scripts in Javascript or some other language, akin to the MOO scripting language. But it doesn't have to be used that way.
Certainly the non-sandbox ideas that I wanted to pursue would be built on top of the core, with the read-only verbs from the Sandbox, and procedural generators creating the non-volatile object store. That is more akin to your use case where it is a foundation for development.
But my assumption, which may be a naive assumption, is that Java as a programming language is not very accessible to the visually impaired. That's why my thinking went in the direction of small nuggets of scripting done from within the environment. If that's not the case, then the distinction between code and data is much clearer, and just some sort of data merge facility would have to exist to test and then roll out changes. If scripting in the environment is more consumable, and logic can be authored in the environment, something much more sophisticated is needed.

So this has set off a few more ideas rolling through my mind that need time to gel. I'm a big fan of test driven development, and even for a personal project like this I have a parallel unit test project (jo.audio.loci.sandbox.test) that I used while developing to test new features and catch regressions that any of my changes caused. The tests are all in the form of "say this, and then ensure these words are, or are not, in the output". Having some sort of formalized tests associated with a project, and changes to a project, might be part of a mechanism to validate merges.
Years ago when I was writing test automation tools, I had a colleague who had devised a system that would kind of randomly shuffle your existing scripts and do them in different orders to look for bugs. I did not think that was particularly useful for a Word Processor, but it might have a roll here. So, I said that for tab completion or fuzzy matching, I would need to be able to create the span of all possible inputs. In a testing context, this could be used to generate a series of correct, although random, commands. With an initial starting condition, one could run a few thousand of these, and save off the end condition. (My scripts currently run at about 100 commands a second. A real system would be slower, but probably enough to make this too slow.) You could do a few of these and save the results before a merger, and then after a merger, to search for regressions. Truly new functionality will throw it, of course. I need to think about if this helps or not in creating a CI/CD type pipeline.

Thumbs up +1

2020-11-24 17:10:06

So, I've been thinking about this, and have some ideas.

In what I've got so far, the fundamental objects are JSON objects. The Java wrappers just provide convenience functions for accessing them. This is not a requirement of the system, but it could be. Either way, the Data Store interface could be extended with a requirement to provide an export function, that returns a JSON object representing the totality of information needed to persist its state, and an import function that replaced the current state with the state represented by the JSON argument passed in. With this, the system as a whole could provide import and export functionality by just calling each Data Store and aggregating them into a larger construct.

Given two JSON structures representing two states of the system, you can construct a method to define the differences between those two structures. And, giving a unique ID to each state, allows for a checkpoint system to be created.

When a deployment is started, it is initialized with a saved checkpoint state. (Or a null, default checkpoint, if it's the first time.) Subsequently, when a checkpoint is requested, it references the initial checkpoint state, compares it to the current state, and saves a new checkpoint that includes the initial checkpoint, plus all the deltas between that checkpoint and the current state. This new checkpoint replaces the initial checkpoint in the running system.

Essentially, as each new checkpoint is requested, another "layer" is added to the file. Playing through the layers applies each block of changes to the base data to come to the current state. (If you are familiar with Docker images, you can see where this idea came from.) With that chronicle of history, it is trivial to "back out" any changes in reverse chronological order. It is possible to back out individual changes, not in direct chronological order, with the risk of leaving the system in an undefined state. So you would only want to do that with caution.

That gives you a method of dealing with simple, linear changes. To support parallel work, you need trees. Consider that you have a staging server, that represents some work people are collaborating on. At the start of a task, you can take a checkpoint from that server, and use that as the basis for development on a local server. When you have completed your work, you checkpoint your own local server and can begin a merge process to the staging server. First a new checkpoint is made on the staging server, incorporating any changes made since you took your own checkpoint from them. That checkpoint is compared to the checkpoint of your local server. At some point, the two history trees intersect, since you started from some previous version of that server. Any changes to the staging server made since your branch started need to be inserted into your own branch. Conflicts can be warned about, and breakages may occur. It should be re-tested at that point. If everything is accepted, then a new local checkpoint is made. This one will only differ from the staging server in simple appended layers. These can just be appended onto the integration sever to incorporate the changes. Local and staging are now running with the same state, the new features have been incorporated.

This is not unlike how Git works. I'm trying to think of how to make Git the backbone of all of this. But I've never been happy with Git's merging capabilities. So I'm unsure.

Progression from a staging server to a production server would work in, pretty much, the same way.

This covers isolated work on people running individual servers for development. There may be a way to encapsulate truly collaborative work. Any change that someone makes is, effectively, and update to a property on an object somewhere. If it is also tracked who made which updates, it should be possible to make a checkpoint from a given position only including a specific person (or group's) changes. That would allow for selectively backing out changes from individuals, or creating something equivalent to Git patches based on an individual's work. Even if that work was done on a collaborative server. This would need some overhead to track, but if the values are retained in the checkpoint file, and flushed from live representation after a checkpoint, that should make it manageable.

A maintenance concern is that each layer in a checkpoint file adds more processing. To compute the final state, you need to start with the initial state and apply each change in succession. That will eventually become cumbersome. In Docker images this is alleviated by having the ability to "squish" images, and combine multiple historical layers. That's a technique that would work here as well.

A practical concern is that some changes are highly relevant (code for a verb on a base object), others are a lot less so (changes to the containment hierarchy by someone walking around). Less relevant changes will cause a lot of thrash in the layers if they can't be detected as unimportant and excluded.

This system should work well with a robust testing environment. Given a set of unit tests that validate functionality against a known state, a change can be approved if those tests run successfully against the new state. If automated appropriately they could be used in an integration pipeline to approve incoming changes to a base stream. If logs are kept of user interactions on the production server, those could also form the basis of further tests. For example, before rolling out an update, those interactions could be played into a test server with the new code to ensure that either the same results happens, or there are changes based on known work.

Anyway, let me know if that addresses some of the concerns you have raised about what is lacking in current collaborative MUD development and if such a system would be worth doing.

Thumbs up +1

2020-11-24 18:52:53

lol I connected toaudio.servegame.com 8080 and just keeps connecton closeding me

If life gives you lemons, turn them into bananas and give them back to life.
My playroom account for contact.
Chatpack soundpack
Oh also my favorite song atm.

Thumbs up

2020-11-24 20:36:22

It was down last night, but I kicked it up again this morning. You need to be sure to use http not https, and you need the colon 80 80 at the end of it. No spaces.

Thumbs up

2020-11-28 23:47:00

I moved my prototype Six Thieves over to the new engine.

Web interface: http://audio.servegame.com:8080
Telnet interface telnet://audio.servegame.com

I had to juggle some of the internals, but the core can now discover all possible commands for any given game point. I've used this to implement tab completion (using tab and question mark) in the telnet interface, and auto-complete in the web interface. Both are a little rocky.

The game, itself, is really just a geography right now. 18,000 houses, 200,000 rooms. You can explore the streets, houses, rooms and rooftops. To be added are the D&D mechanics so skill roles are rolled by the back end to climb walls, move silently, open locks, etc. Valuables need to be generated in houses to steal, and fences to sell them too. And NPCs to populate the houses and call the city guard if they wake up and find you. Eventually guild structures allowing access to better fences, special equipment and missions.

Feedback welcome on the game concept, and interfaces.

Thumbs up

2020-11-29 17:55:29 (edited by moaddye 2020-11-29 17:56:35)

sounds cool. cept, what coding language will this be in? how will players get programmer status if I'm understanding this right? etcetera

If life gives you lemons, turn them into bananas and give them back to life.
My playroom account for contact.
Chatpack soundpack
Oh also my favorite song atm.

Thumbs up

2020-11-29 20:04:52

@moaddye - in trying to be a like a modern LambdaMOO, there are two layers. The low level fundamental intrinsics are in Java. The City of Thieves concept I have up now is an example where a procedural world was built up, in Java, on top of that layer. The Sandbox concept I had up before was a user extensible layer built on top of the intrinsic layer. Players can add their on content in the context of the game. Programmatic extensions were not implemented in that prototype, but the way that would be done would be through adding in scriptlets in a language embeddale in Java. Javascript would certainly work. I'm told there are embeds for other languages such as Python, but I haven't been able to track one down. I could probably write my own BASIC engine if someone really wanted that.

The sensible way to do it would be to make it an admin privilege to give the programming privilege out. That makes it an administrative decision rather than a technical one.

Thumbs up

2020-11-29 20:34:09 (edited by queenslight 2020-11-29 22:45:15)

Oh wow!

I wonder if this MUD has/will have apartments.

This is gonna be fun!

I'm not into the RPG  enforced kind of life, but more power to those who are.

By the way, if you see a character named Sulien, that would be me.
The name Sulien is a boy's name of Welsh origin meaning "sun born".



2020-12-01 16:46:40

I'm glad you like the concept. I had thought about player acquired buildings, mostly in the context of setting up guilds. But there is no reason it couldn't be more widespread. It's not like there is a shortage of them! Right now I'm adding in contents to the houses, so there's something there to steal. Right now there's only 15-20 basic building types. So to expand on that, and give a more controlled means of adding contents rather than just generation, I'm re-tooling the editor I have for creating building templates.

Thumbs up

2020-12-01 17:16:22

@jjaquinta would Jython work in this instance (python running on the JVM).
It's been a long time since I've worked with Java, so don't really know much about it's ecosystem these days

If you like what I do, Feel free to check me out on GitHub, or follow me on Twitter

2020-12-01 17:43:18

The programming language needs to be sandboxed and, ideally, you need to be able to limit execution time.  Jython isn't suitable for either.  JS is suitable for sandboxing as long as the Java Js implementation (nashorn I think) doesn't expose the standard library.  Lua can get you both.

If you're going to only give programming to some people and the goal is to be a moo, then everyone who wants to play a moo is going to go use moo, because it has proper programmer permissions and things that let anyone who wants to build a thing use it.

Don't write your own scripting engine unless you have experience with such things.  Everyone who says "I can just write my own scripting engine" eventually ends up with something weird and nonstandard, usually with bugs, and often very slow.

My Blog
Twitter: @camlorn38

2020-12-02 01:33:01

Agreed, if programmer permissions give you access to something that can escape the environment, someone could either inadvertently, or intentionally damage the machine or database it's running under.

Wake me up when the world has unfucked itself
Is time really linear?
You can find me on discord: ironcross#8090, though I don't know why you'd want to.

Thumbs up

2020-12-02 06:17:55

@NicklasMCHD - I was going to say that Jython hasn't been updated in 5 or so years, but I just checked and there is a 2020 edition. So that certainly is an option.

I've written a number of scripting engines over the years. Mostly to add macro languages to both personal and professional applications I've built. My first preference when working with Java is to just use the built in Javascript one.

Given the way it is structured in Java, you can actually support multiple scripting languages. I did that for one of my products at work. It allowed for backward compatability for existing macros when we moved from my scripting engine to Javascript.

Thumbs up

2020-12-03 02:36:38

I just want to be on the record as saying that, unless Jython has special sandboxing support, Python sandboxing literally just isn't possible.  It's not an option unless your goal is now to be a normal hack and slash mud where the focus isn't on user-created content.  Every time someone has "sandboxed" Python, it's lasted all of one halfway competent hacker.  Maybe your goals have changed but, if not, using jython will certainly change them for you.  So will using the Java JS implementation, unless it is possible to entirely turn off the standard library.

Aaaand to get ahead of the inevitable "but Python isn't sandboxable therefore we can't use it" threads that me pointing this out will inevitably start: it's fine as long as you aren't running untrusted code, making your audiogame in it isn't insecure, just don't make your MMO server accept Python from anyone you don't want having access to everything the game can do and possibly also the rest of the server with basically no effort.

My Blog
Twitter: @camlorn38

2020-12-05 18:48:06

I tried to click the web interface link in Brave and it just didn't work, but my main question is how does this differ from something like ChatMUD which also has custom building and programming support, besides the idea of a custom scripting language?

I like to sleep, Sleep is good,
This is how I do it: Lie on a nice warm cozy bed, and dream dreams about how to rule the world!
Follow @TheGreatAthlon5 on twitter for humorous facts and game updates!
If you like my posts, thumb me up!

2020-12-09 23:36:38

@keyIsFull, I had not seen ChatMUD before. It's difficult to tell from the doc what it does, but it sounds much the same. If it already has every feature you think you will need, then it sounds like what you should go for.
Given the general thrust of comments here is "why this is bad" instead of "this is what would make it good", I'll pass on the scriptable sandbox implementation. I'll build my own stuff on the Java layer.
If anyone is interested, the City of Thieves prototype is more playable now. You now have to use your thievery skills to lock and unlock things. I'll post a separate thread when I have a full play cycle of break in, steal object, fence object, gain XP going.
Web interface: http://audio.servegame.com:8080
Telnet interface telnet://audio.servegame.com

Thumbs up