@Darren said in Learning Ruby for Ares:
The real beauty of it is, once you figure out how models work, you can apply that knowledge to Evennia, too since they're quite similar.
Indeed. The concept of database models is pretty universal in any kind of modern application using a database. Pretty much across the board, the programming skills and tools you learn doing Ares or Evennia will translate well to other non-MU programming.
@JinShei said in Health and Wealth and GrownUp Stuff:
And a dozen other things known to medics. 80% of chest exams are done with listening and looking, and not by pain symptoms. So. Yes, could be those, or something else. I could list a dozen other things but the thing is - without a physical exam, I can't tell. And I'm trained to be able to diagnose.
Echoing this as another medic. There are dozens of things it could be. Telling somebody not to go to the doctor because there's "probably nothing to be done about it" is not only bad advice, but potentially dangerous advice.
@Darren said in Learning Ruby for Ares:
Basically she means that Ares doesn't have anything like MUSH attributes which allow you to store random data on any object. Persistent data needs to be stored in a database model and the model will have to be designed specifically to hold the data that you want to store.
In case anyone's curious... here's a couple quick examples of how this works.
Say you want to just add a simple field to all characters for their favorite color.
Penn/Tiny Version:
&favcolor *Bob=Blue # Sets Bob's favorite color
get(*Bob,favcolor) # Returns "Blue"
Ares Version:
class Character
attribute :favcolor
end
Character.named("Bob").update(favcolor: "Blue") # sets Bob's favorite color
Character.named("Bob").favcolor # returns 'Blue'
The main difference is that we need to define the attribute ahead of time via code before we can use it. As Darren said, we can't just wing it and and set any random attribute from within the client.
ETA: Oh, and the other big difference being that Ares code is generally edited server-side and not typed raw into the client.
Now let's say you wanted to have weapon objects so Bob can have a gun:
Penn/Tiny Version:
@create Weapon Parent
(some other code on the weapon parent to control what the weapon does)
@create Bob's Gun
@parent Bob's Gun=Weapon Parent
&ammo Bob's Gun=10
&type Bob's Gun=Blaster
give Bob's Gun=*Bob
Ares Version:
class Weapon
attribute :name
attribute :type
attribute :ammo
reference :character, "AresMUSH::Character"
(some other code on the weapon parent to control what the weapon does)
end
gun = Weapon.new(
name: "Bob's Gun",
type: "Blaster",
ammo: 10,
character: Character.named("Bob"))
The main difference here is that in Ares the 'shoot' command would live in a separate command class. It would utilize properties of the weapon class; the commands are just not tied to individual database objects.
The syntax is different obviously, but the core ideas are still the same.
@skew said in Welcome to Chontio! A Star Wars MUSH:
Also, AresMUSH has a very handy feature that parses your entire wiki (including character pages and logs) into HTML (thank you @faraday , you're awesome), which I've used.
If you want to dropbox/box.net/whatever that to me, I can add it to the AresCentral Archive.
I offer this for all closed Ares games.
@Darren said in Learning Ruby for Ares:
Persistent data needs to be stored in a database model and the model will have to be designed specifically to hold the data that you want to store.
Ruby also allows you to extend existing classes. You have to judge whether the data you want to store can fit onto an existing model or warrants its own.
If all you want to add is a goals field, you can easily do that by just adding a new attribute to the character model. Something more complicated - like a spaceship - you'd want to define a new model for that.
@Derp said in Learning Ruby for Ares:
I'm leaning toward a more traditional inventory system based on objects for a couple of reasons, really...First -- while what I want to do could probably be done with a database, I'm not sure how to do it in a database, and it might be more complicated.
Well... if you want to store something in Ares dynamically, you're gonna store it in the database. There's just no other way to do it. (By dynamic I'm excluding static configuration settings, like 'a broadsword always does d6 damage'. Those you can chuck into config files, like FS3's weapons config.)
The difference between Ares and other MU code systems is that most traditional MU code systems have four classes of objects - Characters, Rooms, Exits, Things. Things being the "yeah anything that isn't one of the above gets shoved in here, and you can kinda use parentage to classify them". They also then have a separate storage system for mail and channels (typically).
Ares doesn't really work that way. It has the big three types of objects (which we call database models in AresLand) - Characters, Rooms, Exits. But then it also has a zillion more. Scene. MailMessage. ForumPost. Pose. Damage. PageMessage. Channel. WikiPage. etc. etc. etc.
So there's nothing wrong with creating an inventory system based on objects (database models). What I was saying is that whatever system you came up with, the db models are going to be specific to your inventory system, and not some generic "Thing" object that could be repurposed easily in some other system and/or game.
@Darren said in Learning Ruby for Ares:
Honestly, now that I've done it, I'm thinking about not using it since objects are really little more than just "desc" holders and there are other ways to do that without needing real objects for it.
That's why Ares doesn't come with an inventory system built in (or "thing objects" for that matter). Everything they're traditionally used for can be done in different ways. There's a discussion about this in the chopping block article.
An inventory system could still be useful in conjunction with other systems though. FS3 for instance relies on storytellers to adjudicate sensible weaponry. The system will let you equip a rocket launcher, but that doesn't mean you have a rocket launcher.
If you wanted to eliminate the human factor there and track someone's gear, you'd need an inventory system. Most likely the basis of it would just be a simple list of gear items, which is simple enough. But then you'd also need to figure out how people get gear, what gear is available, what the gear does, how it relates to other systems (like combat) ... all of which is highly game-specific. It can be done, but I'm doubtful that it can be done generically.
@Auspice said in Learning Ruby for Ares:
Well, one spoke up and went 'Oh hey! It's the book I learned Ruby from.'
Yeah it's great, but I think it works best for someone who already is familiar with another programming language. My impression was that it wasn't well-suited to somebody learning from scratch. YMMV.
@nyctophiliac said in The Art of Lawyering:
Just why would anyone ever want to be tried by a court of their peers when the majority of our peers aren't all that smart - why not rely on a professional with experience? (Like a Judge!) Does this happen anywhere other than America?
While others have talked about the origins of the practice among the English nobles, one needn't look that far back in history to see why some might think it was a good idea. "He's a hanging judge" in the American 1800's comes to mind, as well as more modern examples where judges have been shown to be corrupt and/or biased. Whether that counterbalances the argument that juries are unqualified/etc. is open to debate.
Other countries do have trials by jury, though I read that much of Europe has done away with them.
@ZombieGenesis Yeah, having a specific project in mind helps a great deal.
It's good to start with a modest project, as you described.
Diving in with "I know no Ruby at all so my first project shall be a full-fledged Shadowrun chargen" is probably not going to have a happy ending.
It largely comes down to preferences and learning style.
Some folks prefer to just take a basic intro like Try Ruby and then learn the rest by tinkering. The Ares coding tutorials are a good starting point once you have the basics of the language down.
Others would rather take a more in-depth Ruby course, like the ones at Udemy, Pluralsight, CodeAcademy, or many others. I don't have any specific recommendations on that front.
It's worth noting that if you also want to make web portal modifications, you'll eventually need to learn Ember Javascript in addition to Ruby. But it's suggested that you get familiar with the MU-client side of things first before diving in to the web side.
I'm not sure what you mean by "while actively constructing the game". Unlike other MUSHes, Ares comes with much of the code you'll need out of the box. So you can still play, chat, etc. while you're off crafting whatever skill/magic/etc. systems you want custom for your game in a separate test/development instance. Typically you'd make sure the code was solid and well-tested before 'promoting' it from the test instance to the real game. So you can definitely do that in parallel with setting up the wiki, building, configuring the plugins, etc.
@surreality said in Firefly - Still Flyin':
The one issue I have with the suspect flag is that it's a double-edged sword.
That's quite true - SUSPECT is not a great tool because you only see half the conversation. Many comments are innocent enough out of context (though it can also work the other way around too).
I'm actually surprised that more MUs don't do what pretty much every public platform does: Log everything, and only review to verify a complaint.
If I report Bob for abuse on Discord or WoW or Gmail or Facebook (etc. etc.), they're going to check the thing I reported, decide whether Bob did something wrong, and act accordingly. They're not going to henceforth monitor all of Bob's conversations - tromping on the privacy of everyone he's chatting with - just to try to catch him in the act or see if he's also abusing someone else too shy to come forward. And I think we'd all be pretty pissed if they did.
The issue with most MUSHes is that a lot of stuff isn't logged to begin with, and client logs can be easily doctored. So instead of just being able to check a chat log and see: "Oh yeah, Bob was being a total creeper", everything devolves into they-said/they-said.
Ares' solution to this is to let people forward abusive conversations from within the game. That way there are no client logs involved, and reporting abuse is as easily as clicking a button (or typing a command).
There is some privacy cost to this, because more things are stored in the database than on a server like Penn/Tiny/Rhost. But the bottom line is that when you're communicating with a private server, every byte of data you send is able to be logged and/or monitored. You're entirely reliant on the game staff to be up-front about what they intend to do with that data, and then to follow through on their promises.
ETA: A lot of this thread should probably be moved to a separate one. It's not really Firefly specific.
@Browncoat said in Firefly - Still Flyin':
hasn't been aware of the SUSPECT flag. This is our first rodeo with FS3.
Just to clarify... SUSPECT is a flag built into PennMUSH. It has nothing to do with FS3, which is just a skills system that runs on Penn and AresMUSH. Most servers have some sort of toolset for abuse management, and it’s an unfortunate necessity that staff be intimately familiar with those tools. I think there’s a thread around here about that somewhere, detailing the tools available on the various servers.
@Browncoat said in Firefly - Still Flyin':
So if we see Player X with another character in a private room, we may go and take a look to see if these complaints are justified and have to call him/her to order.
I'll echo what others have said about kudos for being transparent about your intentions, and also for just the organization/clarity of your wiki as a whole. Nice job.
But I think there's a flaw in your reasoning on the spying thing. Say you've gotten some complaints about Bob, maybe even warned him that he's been complained about and his scenes might be subject to monitoring.
Now you see him and me doing a scene in private, so you pop in to see what's going on. Firstly, you're now invading my privacy based on a complaint that has nothing to do with me. If I'm getting creeped upon, I can just complain to you myself and submit a log to you. Secondly, creepers aren't generally creepy all the time , so you run the risk of negative confirmation bias. "Oh, well, we popped in on four of his scenes randomly and it was fine, so the accusers must be making it up." It's just not a very effective strategy IMHO.
It's not a question of "rights" here - you certainly have the right to do it. You just have to weigh whether the "last resort" kind of situation you're describing is worth establishing a policy that's going to chase good people away.
@Groth said in What is the 'ideal' power range?:
For a long while now I've been a fan of the idea of keeping the power level of PCs relatively level while trying to find ways they can feel they're shaping the game world itself.
I think FS3 games show that this philosophy can be successful. Anne and Bob may start out at different levels, but we're talking "rookie vs veteran" degree of difference here, not "Darth Vader vs Wedge". And the level difference depends more on where you started than how long you've been there.
You can start with level 6 (out of 7) in both Piloting and Gunnery if you want, yet you don't see Viper pilot players leaving in droves like: "Wellp; I've maxxed out my skills. There's nothing more to do here." There are other ways to measure achievement -- story arcs, relationships, thrilling heroics, even to a lesser degree medals, victory tallies and promotions.
Getting back to @Arkandel's original questions, I don't think there is such a thing as ideal power level as a universal constant. I think that there may be an ideal answer for a particular game depending on what kind of game you're trying to build.
@Arkandel said in What is the 'ideal' power range?:
So does the existence of PvP/PK and/or a +warn mechanism relate to whether the power curve is normalized (and where) on a game?
I think it does. It's like how many (most? all?) MMOs do level-bracketed PVP. It isn't really fair or particularly fun if you've got lvl 1 people going up against lvl 100 people. But how do you do that in a pure open world like a MU where anybody could be pitted against anybody else at any time?
That's one of the reasons why I warn people in the game design section of the FS3 docs that it isn't well-suited for PVP games. The way chargen is structured, it allows two people to spend an equal number of points but walk out of chargen with essentially different "power levels". That's OK when one of them is the rookie under the wing of a veteran against a common enemy (as long as the rookie doesn't feel completely marginalized/useless in plots, as I mentioned earlier) but it's not particularly fair if you are putting them against each other IMHO.
I mean there's always the "life isn't fair why should the game be" mentality, but I'm not a fan personally.
@Ghost said in What is the 'ideal' power range?:
I may be opinionated, but IMO IC PVP/PK is a tool/lost art that never should have been completely taken off of the table.
Who exactly took it off the table?
it's no secret that I don't favor PVP (I get enough drama with people's egos and undue investment in their chars on PVE games, thanks) but even my games don't have a prohibition against it. Heck, one of the plots on BSP (inadvertently) pitted mutineers against loyalists.
It may have fallen out of favor, but there's nothing stopping anybody from making a game that features it.
@Ghost said in Good or New Movies Review:
Nope, at least not "kid like" kids. It's just a shame to see Disney pushing the button hardcore on all of these characters that aren't their flagship characters. A good Pixar-type Mickey and the Gang movie might be fun.
As @Derp mentioned, they push those characters a lot for the preschool-age crowd. There are multiple TV shows, TV movies, toys, music -- oh dear lord the Christmas music; I'm going on ten years now of listening to Goofy singing White Christmas every year... trust me, Mickey and the Gang are alive and well 
I am surprised they haven't tried a full theatrical release though.
@Ghost said in What is the 'ideal' power range?:
MU Story RPG=Free form. Statless super hero games. Universal dice systems like FS3.
I generally agree, and would just add to that list “stripped down or lightweight versions of TTrPGs that are clearly identified as such”. Th is is not a unique idea even in TT circles. Some games expressly make light versions for new players, cons, or a more narrative feel.
We once did a TT Dark Sun campaign using Shadowrun rules. We shouldn’t feel boxed in. The most important thing is to pick a system (or lack of system) that supports your vision and goals for the game.
@gryphter said in Model Policies?:
Policies cover everybody's asses.
I do believe that you need more than JUST a “be excellent” policy, but I don’t think you need a ton of detail either. If your policy files are huge a lot of people won’t read them anyway.
I view it like going to a club or restaurant or even someone’s house. They don’t need to spell out all conceivable ways someone might misbehave badly enough to be shown the door. It’s mostly common sense.
Enforcement doesn’t have to be draconian either. If I see a channel convo going off the rails, or somebody making an inappropriate joke, all it takes to clarify expectations is a polite “let’s not do that guys”. If the behavior is pervasive maybe I’ll make a bbpost and or add it to the policy but it’s overkill to do that for every possible misstep.