Posts made by faraday

@Thenomain said in What is out there? Hard and soft codebases of choice.:

Actually, here, let me suggest this:

1. Pre-MUD (Adventure, etc.)
   <snip>

I think we have a fundamental disconnect on what makes a MUSH a MUSH. Is it a style of game or a style of server? Both? Neither? Kinda? I have a feeling there was a thread about this once upon a time. But depending on your definition then it's either completely possible to make a MUSH in a server like Ares/Evennia or it's completely impossible. AresMUSH is a MUSH server by my definition. And since I'm the one naming it, well...

And that's what I see in this discussion. "Well you can do THIS," says server advocate A. "But you can't do THAT," says other server advocate B. "But THAT is different than THIS," says server advocate A. "But THIS is different than THAT," says other server advocate B.

Evennia is different than TinyMUX. We know this. Look up. No, more up. Look at the first post. Look at the question posed:

Isn't that kind of the essence of the OP's question though? What makes each server different/special and why we like them?

Obviously we shouldn't be starting holy wars or being overly defensive, but well-reasoned explanations of the pros/cons of A vs B seem to be on-topic?

@Griatch Right, just bear in mind that vanilla Penn/Rhost/Tiny doesn't come with a lot of that simple stuff. So "game devs" use softcode for +finger/+help/+where as much as they do the advanced skills/combat foo. And the little stuff is achievable by a much larger audience of coders.

@Griatch said in What is out there? Hard and soft codebases of choice.:

I could personally not imagine writing a full game in anything lisp-like, but that just shows my bias. All the more power to you.

I think it depends on what you consider a "full game". +finger, +who, room parent descriptions... those are relatively easy to customize and learn once you learn a few MUSHcode basics. Where the gap exists is in the more advanced systems - sophisticated chargen, combat, economy, etc. There I respectfully disagree with @krmbm that you do have to be a pretty advanced MUSHcoder to accomplish. That's why a lot of people use Theno's WoD system or my FS3. Of course, many games don't need those things.

@WTFE said in What is out there? Hard and soft codebases of choice.:

For example, there are other embeddable languages out there that you can incorporate into a custom server that will bring you up out of the stone age. Off the top of my head I can cite Lua and Tcl as possible contenders (with Lua going more up the list because it's quite a bit more modern and popular a language).

Well I can't speak to Evennia since I don't work on it, but I initially looked into doing a (something)/Lua combo for Ares but settled on Ruby because the overall package felt cleaner. Yes, you sacrifice in-game scripting support but you only need to learn one language. There are other technical advantages (which is a ramble far off this topic but which I'd be happy to discuss offline if anyone's curious). It all boils down to goals and tradeoffs.

Nothing wrong with your list of ideals for a MU* replacement. I just have a different priority list. It's all good.

Now factor in debugging to find the problem. It's a lot easier to debug a system that gives you its guts at point of usage...

Personally I've found debugging in Ares to be WAY easier than in Penn. I have actual log files when something goes wrong, and I can chuck in debug statements, inspect variables, etc. Again, yes, it requires you to have a separate window open, so maybe that's a deal-breaker for you. YMMV, I can only speak for myself.

@WTFE said in What is out there? Hard and soft codebases of choice.:

In the end I may finally implement the program's final version in a compiled language, but nothing beats a hosted interpreted language (or a language whose compile/link/load cycle is so fast it emulates one) for raw exploration of concept space.

I completely agree with you that this is MUSHcode's strength. And if that's your primary goal in your game and you're willing to learn MUSHcode to do so, then clearly the first-gen MUSH servers are for you.

But as @Griatch pointed out, the workflow for Ares/Evennia is nowhere near as onerous as the C example you cited. I logged in yesterday and someone reported a bug in the mail system. I fired up my SSH client, edited one file, typed reload and voila - the bug was fixed in about 2 minutes.

Yes, it requires an extra step of having an ssh client running in a separate window. No argument. But IMHO that is an extremely minor addition to the workflow. And in exchange for that small amount of friction, I get, among other things:

• Coding in Ruby instead of in a 30-year-old derivative of a language (Lisp) that nobody uses any more, with all associated benefits (off the shelf libraries, whitespace, comments, community help, editor tools, etc.)
• Easy version control, without having to run things through a MUSHCode formatter/unformatter, with all associated benefits (history, merges, backing out changes, easily accepting contributions, etc.)
• Seamless sharing of code between my local development environment and the real game server. (Having a local environment is an option, not a necessity, but one way to address @Thenomain's point about fiddling with code before publishing it live.)

If none of that appeals to you, that's totally cool. First-gen MUSH servers aren't going anywhere. My goal with Ares is not to replace them, but to provide an alternative that makes it easier to install, play, and code a game. If nobody uses it but me, I'm fine with that

To @surreality's question about out-of-the-box config, I'd say that's another core difference between Evennia and Ares: Evennia is set up with basic "talker" commands like Penn/Tiny, without the game-specific stuff. Ares comes out of the box with all that plus all of the things you'd normally find in a softcode package like mine/Volund's/Theno's. (List of AresMUSH Plugins) It's a difference between open MU* framework vs. MUSH-in-a-box.

@Thenomain said in What is out there? Hard and soft codebases of choice.:

@faraday

I've been using: Mushes, Mushlikes, Mushcode. The last was more popular long ago.

Also, long ago about half the mushers coded. Code was simpler, and the requirements to entry were lower.

Ares is a MUSH though. I chose that term deliberately because from a player's perspective (and by that I mean one who is playing the game and neither coding nor creating it) it's virtually identical to PennMUSH. I've had players on the Ares alpha/beta games that didn't realize they were playing on a completely different server. They thought it was the stock Penn-FS3 setup with a few tweaks. (Which is exactly what I want, btw, to ease the transition.)

Anyway, yeah - long ago coding was more common. But I'm not trying to get back to the MU*s of yesteryear where everyone was making Falcon Controllers. I'm addressing the use cases of the types of games I see and play on, where you've got (if you're lucky) one coder or an admin determined to learn enough to limp along.

@Thenomain said in What is out there? Hard and soft codebases of choice.:

Okay, so if a "game dev" is anyone who can run code...no, that still doesn't make sense. I can log into a Penn game, run some code, and therefore make my own code more portable. I don't have permission to do so, and I'm not a game developer.

Again, I think we're not talking about the same thing.

Yes, on Penn/Tiny, anyone can run code, but the overwhelming majority of people just don't. There are a handful of folks who insist on having their own +ansi or +this or +that code, but they are the exception rather than the rule.

"Game devs" are the people making the code for the game that everyone else uses. On old-MU servers, they're the ones putting globals into master rooms.

If you have a better term that avoids potential confusion, I'm happy to adopt it.

(Eta: And while we're at it, I'd love a better term than old-MU for Penn/Tiny/Rhost, because old sounds unintentionally derogatory. Softcode-based? First-gen? Anyway.)

@Thenomain by actual game dev I meant simply someone with permission to be a coder on a game (in Ares this means access to either the server shell or git repository to push changes). This is in contrast with old Mu* servers where every player can do some level of development. It's a question of access not skill or elitism.

@Thenomain I'm curious how you define "immediate feedback tools". Is changing code in a text editor in the server shell and typing @reload in the game not immediate?

I grant that neither Evennia nor Ares can compete with the old MU servers in allowing any old player to fiddle with the code. But for actual game devs, I don't quite see the distinction that you seem to be alluding to.

@Griatch said in What is out there? Hard and soft codebases of choice.:

I have not personally tried it, no. But from the description it seems like a pretty standard host. I'd agree it's likely not the cheapest or best option, considering you'd likely need at least the "Deluxe" option memory-wise (more for a large production game). Python and GIT are standard packages for any server though and one should reasonably be able to expect them to be available, or ask them to be. As for web services, Evennia is its own web server and runs its own SQLite3 database-as-a-file (unless you want to use MySQL/PostGreSQL/Oracle you don't have to), so it needs no other programs server side and no further root access.

I see your point though, sure. It's great to have an obvious place to go to host and start your game, no denying that.

I think you and I have had very different experiences with what one can reasonably expect to have available on a "standard host".

I feel like I'm straying way off-topic of the OP's original question, but I'll ask anyway: Evennia can run with a web server in 50MB of RAM (the GM deluxe package)? Also I believe you'd have to have a custom port for the web server, since :80 would be taken.

At any rate, if it'll run on a standard MU host like genesismuds or dreamhost or whatnot, groovy. I went down that road with Ares and found it wasn't going to work, which is why I'm skeptical.

Sorry for the double post, but I did the first one on my phone and missed @Thenomain's reply. I agree that having a low "time to project" / "time to playing around" threshold is important. I think @WTFE brought up a great point earlier about bridging the gap from player to MUSH developer.

But I don't think that having the ability to edit code 'live' from inside the game itself is essential for either of these things. I believe that you just need to have an easy setup for a sandbox environment and a clear set of "Hello World" style tutorials ala Amberyl's old MUSHcode tutorial.

Look at FPS/MMO games for a good example of this. You can't design an AddOn or a new level from inside the game itself, but there are toolkits and tutorials to get you going. And you don't need to be a professional programmer to use them.

That's all you really need IMHO.

@Griatch said in What is out there? Hard and soft codebases of choice.:

@faraday said in [What is out there? Hard and soft codebases of choice.](/post

I am a programmer. I am not a system administrator. When you tell me: "Oh, you 'just' need to install SQL, and install Django, and install Python, and do this, and do that, and configure the web server, and get a DNS name if you want one, and oh by the way don't forget about all the security updates..." I just want to run screaming in the other direction.

Contrast that with a typical MU* host where you go to genesismuds, click on a few things, and now you have a shell account for mymush.genesismuds.com where all you have to do is install the game itself with a couple make commands.

(This is not a problem unique to Evennia, btw... I'm struggling with the same thing on AresMUSH. Trying to make the install/config as painless as possible is my #1 goal.)

Well, genesismuds could be used for Evennia (and Ares, I presume) too, it's not like that has anything to do with MUSH per se - it's just a shell account marketed to mu*ers.
Presumably they have Python (and Ruby) installed on their servers or one could ask for it to be. And you don't need to install SQL, nor Django for Evennia yourself. At that point of the install you do pip install -e evennia and it fetches all the dependencies and install them for you
m

Have you tried it? I am seriously doubtful given that you don't have root and there are serious memory and processing constraints. And I didn't think it came with stuff to run a web app but that may have changed. Been awhile since I used them or any other mush host.

Maybe they'd help you set it up, I dunno. My point was that you can't just hit the ground running the way you can with penn or tiny or rhost.

@Griatch said in What is out there? Hard and soft codebases of choice.:

@Thenomain said in What is out there? Hard and soft codebases of choice.:

I still don't know Django. Installing Evennia, more than just getting the raw code on my computer, is still daunting as hell. I strongly support @faraday's notion that it's a rough toolkit, maybe a framework, and little else.

I am a programmer. I am not a system administrator. When you tell me: "Oh, you 'just' need to install SQL, and install Django, and install Python, and do this, and do that, and configure the web server, and get a DNS name if you want one, and oh by the way don't forget about all the security updates..." I just want to run screaming in the other direction. (I know how to do these things, but they're not my forte and thus very un-fun.)

Contrast that with a typical MU* host where you go to genesismuds, click on a few things, and now you have a shell account for mymush.genesismuds.com where all you have to do is install the game itself with a couple make commands.

(This is not a problem unique to Evennia, btw... I'm struggling with the same thing on AresMUSH. Trying to make the install/config as painless as possible is my #1 goal.)

@Griatch said in What is out there? Hard and soft codebases of choice.:

This is probably true, from our previous discussion of the differences. Of course, once you have the server running, the minimal "Python dev environment" in Evennia's case is basically a text editor and that's it.

Well, yeah, but I'm talking about getting the server itself up and running. I've had a bunch of people give up trying to run a game because the PennMUSH install was too intimidating (and it's like a FTP and a couple 'make' commands). Devs take it for granted because we live in a world of command lines and shell scripts, but I think it's important to keep in mind that you've got basically an entire generation now that's never had to use a C:\ prompt. SSH? SFTP? Text editor? You just get blank looks.

These are smart people, but their experience and foundational tech knowledge is completely different than what's required to run a traditional MUSH server.

@Griatch said in What is out there? Hard and soft codebases of choice.:

I cannot really relate to this notion (anymore) as a game developer though - the immediacy of the telnet just doesn't outweigh the advantages of a proper development environment (to me).

Yeah, I'm with you on that one. On many games, players aren't allowed to code much (if anything) anyway. If you want in-game player-accessible scripting support, Penn/Tiny/Rhost is good for that.

Assuming you start with a sane Python dev environment, installing consists of activating a python virtualenv (a standard practice for Python programs), cloning the evennia repo and then running pip install -e evennia.

I think this is the core difference between Evennia and AresMUSH, which is my MUSH server in development. Evennia seems to be more of an open framework - "build whatever you want" - with a presumption that you are tech-savvy enough that you've either started with a Python dev environment or can figure it out.

Ares' goal is to be more of a "MUSH in a box" that someone with no server experience and no coder could get up and running themselves. (Assuming they are content with what the out-of-the-box code can be configured to do.)

That is the principal reason why I opted not to put a web front-end on Ares. Sure it's very cool. It could absolutely be done. But it increases the server and code maintenance requirements and complexity significantly.

@Thenomain said in What is your preferred method of function creation?:

iter( %0, pmatch( %i0 ), if( strmatch( %0, ,* ), ,, %b )

Commas are much easier code-wise, admittedly. But doesn't built-in stuff in hardcode already use double quotes for multi-word names? I'm not 100% sure since I never turn that feature on, but that's what sticks in my memory, like connect "John Smith" password. I assume it would work the same for pages and whatnot. So if you use commas in softcode now the players have to remember to switch.

@Ganymede said in +wantrp Command Suggestion:

Finally, the shy player. Making new code is not going to suddenly change how that player feels about reaching out to others. It is difficult; it can be painfully difficult; and I do not mean to belittle them. That said, I do not see how new code is going to help them, especially if the target player ignores them. They might think: 'well, I sent them something that reminds them constantly that I'd like to RP with them and yet they are still ignoring me.' The unintended consequence of making a player feel even more insignificant is substantial, in my opinion.

+100 for this. Introverted people are probably the least likely to use such a system. (And I say this as an extreme introvert.) I have a hard enough time paging someone to ask for a scene, let alone imposing myself upon a virtual "TODO" list.

@Hexagon That's assuming you want every function on that object to be global. My function objects hold both private and public functions. Only the public ones are registered via @function.

Of course you could get around that with naming conventions like FUN_x versus FUNPUB_x or something. I just find it easier to have the objects register what they need.

Side note about multi-word player names. @Thenomain hit on the main reason why I have chosen not to allow them in my codebases. It's just a PITA for the players to have to put junk in quotes or separate it with commas all the time, and double PITA to parse a quote-encapsulated list versus a space-separated one.

Having six variants of "John" on your game is going to be confusing to people whether you have John Smith/John Doe/Jon Snow or John/Johnny/Jonathan. I find enforcing single-word names to be the lesser of two evils personally. YMMV.

@Ashen-Shugar Penn has a function list too showing the DB# and MU* function for all of the global functions.

APPEND                               16    FUN_APPEND

My code attempts to be modular, so I use separate Command/Function/Data objects for each softcode system. The function object's @startup will register any of its functions it wants to make global.

@startup FS3 Skill Functions=@function roll_ability=me/fun_roll_ability

@Thenomain Unfortunately there are times when adding spaces causes the parser to actually add spaces, which is often not what you wanted. Example: set(me, foo: bar) sets foo to "_bar" instead of "bar" as expected.

I have it in my head that the problem used to be more widespread than it is with the current version of Penn. Or maybe I was just always paranoid. Either way, that's why my MU* code is always squished.