@mietze Yeah, y'all are kinda hitting on the complexities inherent in this, with everyone having their own definitions and expectations. Believe me, I've been round and round on this and haven't come up with a "good" solution. Which is not to say someone else can't come up with something better, just that I have put considerable thought into it and had this same conversation with the Ares community already. Having freeform scene notes seemed like a reasonable compromise.
@TiredEwok said in Netrunner MUDs:
Which came first: Shadowrun or Netrunner?
Shadowrun, by several years. But most of the similarities between the two (and the Cyberpunk RPG) are attributable to the underlying fiction sources.
Not my kind of game but I think your 'pitch' sounds really neat and touches on the important bits, like game focus and what there is to do.
As @ZombieGenesis said - keep in mind that Ares doesn't require FS3. You can turn off the skills system entirely and just go freeform. There are also several other skill systems already coded; maybe one of them will suit your needs better. But yeah, like you said - making your own custom system will be considerable amount of work no matter which codebase/system you choose.
@krmbm said in Why no Star Trek games?:
In 20 years of Pern gaming? I honestly have zero memories of ever having a playground fight about it. So going statless can totally work.
I don't discount your experiences, but mine have been polar opposite. I "grew up" on statless consent MUs, and I would never go back. Too much confrontation and drama. I think it probably depends on the player sub-community you're dealing with.
Comic games are also often consent, so I'm definitely not saying that it can't work. Just that I have my pet theory on why it seems to have fallen out of favor, and it has little to do with advancement.
To get around the persistent connection problem @Tinuviel mentioned, you really need a dedicated mobile app. (Not just a web app.)
This is a huge, possibly-insurmountable, challenge for several reasons:
If we handwave those challenges away, an ideal mobile MU app would look to apps like Discord and Slack. MUs are, after all, little more than glorified chat engines.
This would lead you to things like clickable menus that hide away when you're not using them; persistent background connections with intelligent notifications; a streamlined chat interface; etc.
Unfortunately, all of that is unlikely to happen. I think MUSHing, like many other kinds of video games and apps, is going to stay in the realm of things best done on non-mobile devices for the forseeable future.
@Arkandel said in Is this hobby on it's last legs?:
Us oldbies may even look at that new form and wrinkle our collective noses at it ("that ain't no MUSH! Get off my lawn!") but that's how the cookie crumbles sometimes.
That's how I look at it. I think MUSHers tend to fixate on the hobby as being defined by the technology rather than the core concepts of the gameplay. MMOs of today don't look or play the same as the original Ultima Online, but we still consider them MMOs because there's a certain core that they share in common.
Though just as there are some people still playing old Nintendo NES games via emulators, there will probably always be people playing Penn/Tiny games via SimpleMU for as long as there exist computers capable of running them.
@coin said in Developing a WoD Codebase for Ares:
Really, I could see a CoD game working find on Ares; those things aren't necessary, they're actually usually just artifacts from the way MUs have been doing those games for so long, people think that if a new game lacks them, it's wrong. It's not.
Sure, but it all comes down to expectations. You can play WoD on Discord or a forum with no code whatsoever. There's been at least one Ares game that used WoD just with hand-crafted PDF sheets and the generic die roller.
Like I said - if all you want is a sheet and some roll commands or whatnot, it'll work just fine. It's only the immersive and PVP aspects that potentially are an obstacle, depending on what vision you have for the game.
Constructively speaking, I prefer not knowing the die results and playing through.
Everyone's different of course. I can only speak to the generalities of feedback I've received in the dozen years of working on FS3.
1st edition took advantage of the fact that it's a computer system to have an opaque, non-dice-based roll mechanic, and OMG the resistance was staggering.
2nd edition used a (virtual) dice-based resolution system, but the actual die results weren't shown, only the summary (Good Success, etc.). The sheer volume of "that can't possibly be right" skepticism over bad rolls was still pretty crazy.
Later 2nd ed. patches and 3rd edition prints the dice right there next to the summary. You still get some folks doing a facepalm or whining or whatnot when they roll 15 dice and get no successes, but at least they're (usually) no longer crying foul at the system itself.
@lotherio said in [What's So Hard About Ruby?](
It implies it should be easy to program/code.
Coding is not easy and I don’t believe anyone here was meaning to imply that it was. My comment at least was merely comparing ruby to other programming languages in the context of the original question.
It took you years to get as familiar as you are with Mu Code I believe it would take less time to gain that same skill in Ruby. That doesn’t mean it’s easy
@tinuviel said in A healthy game culture:
ETA: Secondly, suggesting that it is the game bringing out the worst in people removes agency and responsibility from the people. That is never an acceptable answer.
Nobody is saying it's acceptable or good. Some of us are saying it's reality.
It is naive to deny the fact that people behave differently when they are in competition with their fellow players than when they are on the same team as as their fellow players, working towards a common goal. That is just human nature, plain and simple. You see it in sports, in playgrounds, in TTRPGs, in board games, in video games... I don't really see why it's such a controversial stance.
Would it be nice to live in a world where you can play with only mature players exhibiting 100% good sportsmanship? Of course. But c'mon, that's just not the world we live in. It's hardly a surprise that you see more jerk-ish behavior in Call of Duty than in Animal Crossing, because the nature of the game is competitive PVP.
@arkandel said in What's So Hard About Ruby?:
I found coding for MU* was an invaluable experience. .. I would heartily recommend it to anyone who's looking to get into programming or is curious about a different professional path.
20-30 years ago I would absolutely agree. Now? MUSHcode is so far divorced from modern programming paradigms and languages that any concepts you learn from it don't translate very well.
That said, people learn best when they're passionate about the thing they're trying to learn; doubly so if there's a tangible, useful project that can come out of it. So for you if that's old-school MUSHcode, go for it. Far be it from me to stand in the way of anyone's passion project.
But if you're trying to learn it as a generic stepping stone to get into programming, there are better ways to do that IMHO.
@lotherio said in Combat on a Mu:
Just a +attack
In most RPG systems, attacking is "just" a skill roll.
The hard part is:
The more you try to automate these things, the more complex your combat commands necessarily become.
The more you try to leave these things up to the humans, the longer it takes with OOCs back and forth trying to sort things out.
So in practical terms, there's really no such thing as "just a +attack" in any but the most simplistic hand-wavey systems.
@groth said in What's So Hard About Ruby?:
MUSHcode serves as a fairly good introduction to Lisp. Dialects of Lisp and languages similar to Lisp are still used by systems that need concurrency like telecom and financial backends.
That's true, but Lisp languages are such an infinitesimally small percentage of real-world programming that it's kind of like learning some weird dialect language that's only spoken in a far-flung corner of the world. Sure, if you live there or have a specific application for it, it's useful. But in general? Not so much.
Lisp-based languages have different design patterns. Lots of recursion and nested function calls umpteen layers deep. MUSHCode in particular lacks many features of most modern languages - classes, named variables, clear function definitions (to @Tat's point about understanding helper functions) or even comments and whitespace (unless you use a custom offline parser). And the way people generally code in MUSHCode is very different - no source control, editing live on game, putting in your code all smushed together onto a single line. These are things that would be considered unacceptable in almost any other programming venue.
I'm not saying Lisp (or MUSHCode for that matter) is a bad language. They have their niche uses.
But come on... this is ONE function from the FS3 combat system in MUSHCode. Even with liberal FUN_ helpers, t's insane. It's just not a good way to learn how to program. And I say that as someone who has literally taught programming.
&FUN_ACTION_ATTACK FS3Combat Instance Parent=localize([setq(0,u(fun_combatstat,%0,ammo))][setq(1,switch(grab(%2,burst,,),,1,min(%q0,3)))][setq(2,u(fun_weaponstat,%0,recoil))][setq(3,u(fun_range_mod,%0,after(grab(%2,range=,,),=)))][switch(0,t(u(fun_combatstat,%0,weapon)),u(fun_combat_msg,[prettify(lcstr(%0))] tries to attack but has no weapon!),t(u(fun_combatstat,%0,target)),u(fun_combat_msg,[prettify(lcstr(%0))] tries to attack but has no target!),not(u(fun_out_of_ammo,%0)),u(fun_combat_msg,[prettify(lcstr(%0))] tries to attack but is [ansi(hr,out of ammo)]!),[switch(%q1,>1,u(fun_combat_msg,[prettify(lcstr(%0))] fires a [ansi(hm,%q1 round burst)]!))][iter(lnum(1,%q1),[u(fun_do_attack,%0,switch(u(fun_is_in_vehicle,%1),1,u(fun_combatstat,%1,vehicle),%1),unprettify(after(grab(%2,called=,,),=)),add(%q3,-[mul(sub(#@,1),%q2)]),0)])][u(fun_suppress,%1,switch(u(fun_weaponstat,%0,wpntype),melee,0,1))][u(fun_subtract_ammo,%0,%q1)][switch(u(fun_out_of_ammo,%0),1,u(fun_combat_msg,ansi(hm,[prettify(lcstr(%0))]'s weapon clicks empty.)))])])
@ganymede said in Attachment to old-school MU* clients:
You don't need to do anything.
I mean, sure, I can just go play video games instead.
But if I want people to actually use Ares, I'm kinda constrained by the attachment to old-school MU clients.
@Cobalt @Derp I don't think there's anything wrong with you or that you're missing anything in particular.
Ares is massive. Thousands of files. Tens of thousands of lines of code. A website. A database. Two different programming languages (more if you count the templating languages and YAML and CSS).
It's a lot.
The thing is - MUSHcode was a lot too. I remember printing out the function help files back in the '90s and being all: OMG this is overwhelming. I learned it piece by piece, starting out with some dumb little notepad object or something and working up slowly. We've just all had so many years to build up familiarity with it, and probably have forgotten how hard it was to get started.
Another confounding factor is that in Ares, most of the stuff you need is already built. So all that remains is the hard stuff - chargen, magic, and other massive systems. Nobody's starting with their own custom +finger because that's already done for you. And even if you did want to customize it, you have to first decipher what's already been made. So you go from getting your feet wet in the tutorials to jumping right into the deep end. It's hard.
But none of that has anything to do with the language itself.
@derp said in Attachment to old-school MU* clients:
The CLI style interface is really about the only remotely manageable way to operate a game like this from an administrative level.
At least 90% of admin commands are available on the web portal for Ares, and are far preferable than the CLI for things like handling jobs, adjusting stats, setting up forums/channels/etc.
The remaining 10% could be done too, I've just been focused on other things.
@derp said in What's So Hard About Ruby?:
And still, I'm left going -- ok so if I wanted to do 'Strength has a range of values from 1 to 5 in integers' -- how do I do that?
If I do set Strength = 5 how do I tell the game that the 5 is an integer and not a string?
How do I tell it that Strength = Duck is an invalid value in the YAML?
These are great questions for the Ares forums or discord, and there are lots of different ways to do it, but this might help. (I'm winging it, so please don't expect this to actually work right as written)
class AttributeSetCmdHandler
include CommandHandler
# Place to store our ability name and rating
attr_accessor :ability, :rating
# This makes sure you gave both an ability and rating
def required_args
[ self.ability, self.rating ]
end
# This cracks apart our `set Strength=5` into its pieces.
# The ability is trimmed and titlecased.
# The rating is interpreted as a number. If it's not a number string it becomes 0.
def parse_args
args = cmd.parse_args(ArgParser.arg1_equals_arg2)
self.ability = titltecase_arg(args.arg1)
self.rating = integer_arg(args.arg2)
end
def handle
# Read our list of attributes and max rating from the YAML config.
valid_attrs = Global.read_config("yoursystem", "attributes")
max_rating = Global.read_config("yoursystem", "max_attr_rating")
if (self.rating < 0 || self.rating > max_rating)
client.emit_failure "Invalid rating."
return
end
if (!valid_attrs.include?(self.ability))
client.emit_failure "Not a valid ability."
return
end
# update the database. attributes is probably a name:value
# hash, so there's a little extra fussing you have to do.
abilities = enactor.yoursystem_attributes
abilities[self.ability] = self.rating
enactor.update(yoursystem_attributes: abilities)
client.emit_success "You set your #{self.ability} to #{self.rating}."
end
end
@arkandel said in What is a MU*?:
Consider an Ares game which - if you're logged on from the web - will display a generic picture of the room you're in. So when you visit the Blue Hearts bar you'll see a picture of a specific bar on the upper right corner.
Is it no longer a MU*?
I'm still not sure what you're going for, since again it's going to depend on your definition.
@Lotherio didn't consider Ares a MU from the get-go because it doesn't have softcode.
Someone else might or might not consider it a MU depending on whether the image replaced the text aspect.
Based on my original list, nowhere in there was "text only" one of my criteria. And in fact Ares does show pictures alongside the scenes (albeit for characters, not locations... that's more from convention than any technological limitation though; many MUs take place in settings where photos are not readily available so it's just not as much of a Thing.)
@cobalt said in What's So Hard About Ruby?:
I wanted to code a widget that would flip the area a room was at from "simulated weather" to "space", to simulate turning a viewport off and on. And I couldn't, for the life of me, figure out how to get/set the area.
Sorry for the triple post but wanted to answer the pieces separately.
# Set your current room to the space area
space_area = Area.named("Space")
enactor.room.update(area: space_area)
Changing it back gets a bit trickier because you might have to create a temporary storage for "the area it used to be in" or something. Kinda depends how you want it to work.
Regardless, this is not something I would have expected to be super intuitive looking at the 2,000 or so lines of code in the 'rooms' module, so you shouldn't feel bad for not being able to just figure it out at a glance. I'm always happy to help point folks in the right direction though.
@sunny said in Attachment to old-school MU* clients:
Nobody needs one any more! Nobody plays on them anyway, we just choose rooms off a list." Unless that's been just hyperbole and the games DON'T actually exist.
Ares games have three different ways of starting scenes.
scene/start Central Perk and create a scene in a temp room representing Central Perk. This scene can be marked as private or public/open.So yes, in scenarios 2 & 3, you don't actually need a "grid", just a list of available RP locations. Even so, I'm only aware of one Ares game that tried not having a grid, and they ended up creating one anyway to be more familiar.