How much Code is too much Code?
-
@surreality i think for some people the coded stuff /does/ enhance their RP and creativity though. I wouldn’t want to say that someone who enjoys it isn’t being just as creative. I know some of the crisis stuff of RfK drove people nuts but I liked the narrative aspect (it described something of concern/going wrong in your monitored territories), because it allowed me to be super creative in how I narrated back how I would attempt to solve in conjunction with the roll.). Other people would have found it stifling or busywork though.
-
@mietze said in How much Code is too much Code?:
@surreality i think for some people the coded stuff /does/ enhance their RP and creativity though. I wouldn’t want to say that someone who enjoys it isn’t being just as creative. I know some of the crisis stuff of RfK drove people nuts but I liked the narrative aspect (it described something of concern/going wrong in your monitored territories), because it allowed me to be super creative in how I narrated back how I would attempt to solve in conjunction with the roll.). Other people would have found it stifling or busywork though.
The hardest thing I believe with coding systems is to be honest, we really don't have that many real dedicated coders in this micro-industry.
And those few coders we do have tend to not want to code in mush, but in another language be it ruby, python, or even php/javascript/web.
This is a failing of a lot of codebases. They tend to gear to a single language system, and MUSH while incredibly powerful for what it is, is an exceptionally esoteric language that requires a special type of insanity to get good at.
Why I tip my hat at Evennia and Ares who use mainstream languages.
Why I took pages out of other people's books and empowered RhostMUSH to be coded, optionally, in any language the coder wants, with obvious caveats for interface and/or speed limitations.
One thing we, as coders, can do for the end user, even if that end user is another coder?
Empower them. Give them the tools needed to do what they find fun and enjoyable. And make life easier for them to do what they enjoy and want to do.
-
@mietze
I tend to look at coded toys (especially many of the ones on Arx) as Features Not Bugs That Aren't For Me. There's a type of player they are for that clearly really loves engaging with them, but I'm not in that demographic. I do play with some of the stuff on Arx now, but that was only after resolutely ignoring it for like 3 months until it stopped feeling overwhelming/like homework.My own preferences run pretty lean, code-wise, but I come from a free-form background.
-
I just think that my primary yum is narrative. I love writing stuff up and reflecting, and preferably having the mediator dictate what rolls are made. Or to write a narrative for off screen actions in addition to using coded stuff. But that is super labor intensive staff side, and again I’d rather see happy staff than me being able to play to my strengths as a player. I have see so many people genuinely enjoy crafted ascii objects and the like, and it’s not something that speaks to me at all, other than supporting someone who obviously loves what they do (Which I’m always happy to be a part of!). I wouldn’t want there not to be that stuff just because I-player prefer desc- or narrative-only artists /when I play them/. I can do that most places, but there are very few code intense games out there, and they shouldn’t be dumbed down for players like me, if that makes sense.
-
Who here remembers when we had language code, invisibility code, and table code that would allow for spying? This was all stuff players wanted. It got pretty complex, too, and while I almost never used it, people thought it was a lot of fun.
While "fun" is subjective, I still agree that it's the #2 reason to allow code to be heavy. Heavy code is either a lot of little commands, or a code with high complexity.
The #1 reason has been touched on once by Ark and kind of by others: To help staff and players facilitate gameplay. Not "have fun", because as above it's subjective and there is nothing fun about 'stat/set strength to 2'.
To me, code is more like an RPG rulebook. It might have things in it that are fun or funny, but in the end its job is to get you ready for the fun. The dice aren't there to be fun, but tools that you use when you play the game and hopefully have fun.
--
Ninja'd by @Ashen-Shugar:
@ashen-shugar said in How much Code is too much Code?:
One thing we, as coders, can do for the end user, even if that end user is another coder?
Empower them. Give them the tools needed to do what they find fun and enjoyable. And make life easier for them to do what they enjoy and want to do. -
@faraday said in How much Code is too much Code?:
Oh yeah, I should have clarified. My "I hate code" sentiment was in regards to code that butts up against actual RP.
In a way and from a certain point of view a lot of code butts up against actual RP in ways that can't always be predicted.
For instance on HM they changed the way the XP code worked at some point and made it +vote based. Suddenly every other scene was huge since people flocked to public RP to milk them for easy RP. When that system changed those kinds of scenes died almost overnight, proving there was an effect to how people RP and what type of RP they are prone to doing.
Similarly after I manually ran a nWoD scene with 18 people in it I never did it again. I've ran large scenes before but it affected how many characters I accept due to the logistics involved; so that sort of thing affects plots as well.
And so on. But you are 100% right in that games (in more ways than just code) absolutely need to pick their poison, and weigh their choices in terms of what they gain versus what it costs them.
-
@mietze said in How much Code is too much Code?:
I just think that my primary yum is narrative. I love writing stuff up and reflecting, and preferably having the mediator dictate what rolls are made. Or to write a narrative for off screen actions in addition to using coded stuff. But that is super labor intensive staff side, and again I’d rather see happy staff than me being able to play to my strengths as a player.
This actually sounds a little like Arx's @action system, which is literally a system designed to reduce the amount of work necessary for staff to do precisely what you describe. You write up actions for off-screen (or sometimes on screen) resolution, bring in assistants, provide what you think are the appropriate rolls, and then submit it. The system can do all the rolls and tally successes for staff, who can then write up a GM response which automatically goes to everyone involved. If they need to, staff can tweak rolls, they set a difficulty for the effort, etc.
This is the kind of code I think helps the game. Things that increase narrative freedom for the players while reducing staff workload. Sure, ASCII art objects can be fun—I have done my fair share of crafting—but when I think what code benefits game narrative most directly I think about things like @action.
-
All design is compromise.
Though as a coder I try to subscribe to this philosophy:
In anything at all, perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away[...]
(Antoine de Saint Exupéry, Terre des Hommes)
But then, I spend way too long coding even the simplest thing.
-
@three-eyed-crow said in How much Code is too much Code?:
@mietze
I tend to look at coded toys (especially many of the ones on Arx) as Features Not Bugs That Aren't For Me. There's a type of player they are for that clearly really loves engaging with them, but I'm not in that demographic. I do play with some of the stuff on Arx now, but that was only after resolutely ignoring it for like 3 months until it stopped feeling overwhelming/like homework.My own preferences run pretty lean, code-wise, but I come from a free-form background.
Yeah, ideally that's how I hope it comes across, as an option of, 'here if you wanna check it out, don't worry if you don't', but I know that just doesn't work for some people too. I have a lot of sympathy for that, but not sure about the best ways to address it, really.
-
@thenomain said in How much Code is too much Code?:
But then, I spend way too long coding even the simplest thing.
This.
This right here is what I and others have spent a horrible amount of time in Rhost to help with.
We made dev-end tools to give people more options to work outside of MUSH to do so.These tools are:
- @doors -- A method to estabish a TCP/IP connection from within the game to an outside source.
Pros:
- It is a simplistic interface to allow any TCP/IP connection.
- It allows async connectivity so you can mush while connected to the external application
- It allows a fairly unlimited number of connections to external services
- It comes standard with a MUSH/MUD/MOO door
Cons:
- It uses TCP line mode and not character mode
- You have to write your own TCP/IP interface for each connection you want
- You have to know C code to write your connection interface
@DOOR Command: @door Switches: STATUS, OPEN, CLOSED, LIST, PUSH, KICK @door provides control over arbitraty TCP connections that are opened from inside the mush to some external program or service. In order for a door to be available a C-code module must first be loaded by an Admin(*), or compiled statically into the mush server. To see what doors exist on your system, type: @door (*) Not available in RhostMUSH 3.2.4p15 and earlier. See 'DOOR SYNTAX' on a quick listing of commands and what they do. See Also: DOOR_OPEN, DOOR_PUSH, DOOR_CLOSE, DOOR_LIST, DOOR_STATUS, DOOR_KICK, DOOR_WRITING, INTERNAL_DOORS, DOORED, DOOR SYNTAX
- execscript()
Execscript allows you to call an external application, script, binary, or anything else, regardless of the language it is written in, and scrapes the results as a native function to the mush. this allows you to integrate anything externally as an internal function call. Very useful for integrated coding.
Pros:
- It allows you to execute any external binary/script/function/feature as a native MUSH function
- It allows you to push and pull data from this.
Cons:
- There is no real 'call back' feature to it
- You can not have execscript() call internal code interactively and must pass data to and from it
- You can't run processes in the background and scrape the data at the same time
EXECSCRIPT() Function: execscript(<script name> [,<arg 0>,...,<arg 9>]) Note: This function issues a shell interpreter so will have some overhead compared to calling it natively through an API. Requirements: /usr/bin/timeout (on MacOSX link to /usr/local/bin/gtimeout) script/binary existing in ~/game/scripts and chmod u+rx @powered EXECSCRIPT GM or higher Set SIDEFX (with the sideffect EXECSCRIPT enabled) This function executes a script called <script name> in the game directory's sub-directory 'scripts'. It is case sensitive and strips illegal characters (like, .., /, $, etc) from the script name. This requires the EXECSCRIPT @power of GUILDMASTER to use the function. It requires the ARCHITECT level to allow the use of passing arguments to the script. Unlike other powers, this power is not inheritable. You can pass a maximum of 9 arguments to the script not including the script name. The following variables are available from inside the scripts called: MUSH_PLAYER - [%!] dbref# of player followed by name of player. MUSH_CAUSE - [%#] dbref# of cause followed by name of cause. MUSH_CALLER - [%@] dbref# of caller followed by name of caller. MUSH_FLAGS - the flags of the player. MUSH_TOGGLES - the togglesof the player. MUSH_OWNER - dbref# of player's owner by name of owner. MUSH_OWNERFLAGS - the flags of the player's owner. MUSH_OWNERTOGGLES - the toggles of the player's owner. Examples: > say execscript(hello.sh) You say "hello from the script." > say execscript(hello.sh,test) You say "hello from the script with args: 'test'" See 'writing scripts' for help on dos and don'ts in writing execscripts. See Also: POWER EXECSCRIPT, exec_secure
- The lovely API interface.
This is a full grown http header based API call. It's similar to a RESTful API in how it works, but is header driven. You pass it arguments via headers to execute code and tell the MUSH how it's to parse the results.
Pros:
- A fully interactive and restful(like) API that is entirely header driven
- Allows you to push and pull data to and from the mush and execute mush code from within any external app
- Anything that talks normal HTTP 1.1 via liburl or normal url calls will be able to use the API
- Allows rapid connectivity to the mush and has no restrictions on what it can execute
Cons:
- No real callback feature, though you can work around it by having the API use execscript()
- If you queue data from an API you have to use a second API call to gather the results
- No persistent API connection
- No SSL layer (currently) is available
API Topic: API RhostMUSH has a process where it allows API connections to happen on another port. It requires to have the api_port specified to a unique port for the API handler, then various optional config parameters to optimize how the API works. The API, unlike normal connections, allows any valid dbref# to talk to the mush from the API engine. It does this through multi-factor authentication including host match and password authentication. Keep in mind, the API port is NOT the mush port. It is a different port. There is also quite a lot of protection on the API port which will automatically disable the object or the IP from connecting if abused. It uses Basic Authorization and encapsulates. Example of using curl for login authentication to the API's object would be: curl --user "#123:foobar" The dbref# would be #123, and the password you want to authenticate would be 'foobar'. Example curl commands that are used for the API handler are: GET Examples (this is from a command line using the 'curl' application) > curl -X GET --user "#12:ya" -H "Exec: [lnum(10)]" --head http://localhost:2222 POST Example: (this is from a command line using the 'curl' application) > curl -X POST --user "#12:ya" -H "Exec: @emit hi!" --head http://localhost:2222 To have a target dbref# enabled for API processing, please alert a staff on your game as it requires staff approval and authentication to enable the dbref# to be useable for the API sub engine. { see 'help api return' for expected return codes }
Granted, this is not a perfect solution for coders, but I believe it empowers them to do a lot of things in MUSH that would normally be impossible to even consider and contemplate.
Hopefully as time passes RhostMUSH will continue to 'grow up' and continue to be a 'Big Boy'
-
I think the thing I coded that overall people enjoyed the most was the Texas Hold'em deck on Firan, which was basically 100% fluff but let you use IC money and had a few minor tweaks to take into account IC stats (e.g. if you had a great luck stat, you had a tiny advantage to drawing good cards over somebody who had an average luck stat).
But essentially it was just a widget that let you OOCly play actual poker and didn't really facilitate RP in and of itself besides being kind of a prop to social RP around (although iirc there didn't tend to be much actual posing among players apart from quick short ones because it slowed down the hands). It mostly existed (a) just to see if I could actually get it working and (b) to get me out of having to come up with another festival event to run again.
-
I enjoy thinking about codes and systems and economies all that sort of thing. I'll sit down with my game books and make provinces in minute detail sometimes just because world building is fun for me.
While Mushing?
It's a pain in the ass, largely because RPG economics make no sense. Like, in star wars, you can buy a space ship for the same cost that a box of blaster pistols, or two repeaters, or one suit of armour. In every game I've played with a coded economy, being a space trucker was way more lucrative than being a space pirate, so there was a tangible incentive to Don't Bother Adventuring.
-
@surreality said in How much Code is too much Code?:
To me, it feels like homework and paperwork work-work.
Yeah for me a lot of it just feels like busy work. OMG I need to remember to spend my XP / do my +tasks / feed my harvesters / do whatever +job foo is necessary to earn my paycheck / sit for 10 minutes on a +shuttle…. ARRRGH. No. I just want to tell stories with other people. Get all that other junk out of my way.
(This is not a knock against anyone who likes that stuff. To each their own. I just intensely dislike it personally.)
@arkandel said in How much Code is too much Code?:
In a way and from a certain point of view a lot of code butts up against actual RP in ways that can't always be predicted.
Very true. Though I think anything that directly impacts the characters, not the players (such as XP in your example) is always going to butt up against RP. What blindsides me sometimes are subtle things like @SG (I think it was) saying that they didn’t like to RP any more on BSGU because people were mostly using scene temprooms instead of grid rooms. Which is a valid point, but my experience was the exact opposite. So I agree - code can impact the game in surprising ways.
@thenomain said in How much Code is too much Code?:
To help staff and players facilitate gameplay. Not "have fun", because as above it's subjective…
I would go a step further and specify "facilitate the gameplay the staff wants to foster". There’s nothing wrong with telling folks ‘no’ because a requested command doesn’t fit your vision for the game, even if that might please 8 (or even 80) players.
@thenomain said in How much Code is too much Code?:
@ashen-shugar said in How much Code is too much Code?:
That's when you tell them to just screw off and go away right?
Yeah, like either you or I are any good at that.
Apparently I’ve honed that craft more than you guys
@ashen-shugar said in How much Code is too much Code?:
This essentially sets anyone connecting from the matching sites FUBAR and SLAVE, which disables every single command (including LOGOUT and QUIT) that the player can issue while on your game.
They find it annoying. Fancy that!That really works? It boggles my mind that it would irritate anyone any more or less than being sitelocked. Like… you just click the disconnect button? Goes back to: people never cease to surprise in the ways they interact with code.
-
@faraday said in How much Code is too much Code?:
Very true. Though I think anything that directly impacts the characters, not the players (such as XP in your example) is always going to butt up against RP. What blindsides me sometimes are subtle things like @SG (I think it was) saying that they didn’t like to RP any more on BSGU because people were mostly using scene temprooms instead of grid rooms. Which is a valid point, but my experience was the exact opposite. So I agree - code can impact the game in surprising ways.
Yeah, it's stupid. It's not you, it's me. I think I have this sticky idea of awesome temp rooms being for plots, hangout/casual scenes are for grid that I can't shake for some reason. I'm sure I'll get over it one of these days.
-
@sg said in How much Code is too much Code?:
Yeah, it's stupid. It's not you, it's me. I think I have this sticky idea of awesome temp rooms being for plots, hangout/casual scenes are for grid that I can't shake for some reason. I'm sure I'll get over it one of these days.
You're not the only one who's mentioned it though, so I really don't think it's just you! It's all good - wasn't a criticism just an observation of how the changes you think are most innocuous can sometimes mess with peoples' fun.
-
@sg said in How much Code is too much Code?:
@faraday said in How much Code is too much Code?:
Very true. Though I think anything that directly impacts the characters, not the players (such as XP in your example) is always going to butt up against RP. What blindsides me sometimes are subtle things like @SG (I think it was) saying that they didn’t like to RP any more on BSGU because people were mostly using scene temprooms instead of grid rooms. Which is a valid point, but my experience was the exact opposite. So I agree - code can impact the game in surprising ways.
Yeah, it's stupid. It's not you, it's me. I think I have this sticky idea of awesome temp rooms being for plots, hangout/casual scenes are for grid that I can't shake for some reason. I'm sure I'll get over it one of these days.
It's a very hard thing to get over. I have, but it did take time and a concentrated effort. Now that I have? It's great.
Part of it was training myself to check 'scenes' as much as 'where.' Which I'm still not as good at, but I'm getting there. (It also means training the playerbase into setting 'scene/summary' on their scene before rather than after the fact, something I'm not consistent at myself!)
-
@faraday said in How much Code is too much Code?:
@sg said in How much Code is too much Code?:
Yeah, it's stupid. It's not you, it's me. I think I have this sticky idea of awesome temp rooms being for plots, hangout/casual scenes are for grid that I can't shake for some reason. I'm sure I'll get over it one of these days.
You're not the only one who's mentioned it though, so I really don't think it's just you! It's all good - wasn't a criticism just an observation of how the changes you think are most innocuous can sometimes mess with peoples' fun.
What I've noticed in similar situations in the past is that RP tends to 'spill out of' temp rooms once you incentivize the practice.
At the moment what reasons do characters have to go outside their usual circles? What are you giving 'me' in return for taking the 'risk' of meeting up with people I don't already know I like?
Suggestions: XP, useful IC secrets, item crafting options, political advantages (recruiting help for votes, etc), faster skill progression.
-
@arkandel said in How much Code is too much Code?:
At the moment what reasons do characters have to go outside their usual circles? What are you giving 'me' in return for taking the 'risk' of meeting up with people I don't already know I like?
What's being done on BSU with Ares is pretty different than standard temp rooms. They're sort of being tried as grid-replacement (though there's still a grid), so you create public scenes within them. So it's not like the standard holing up in a TP room with your friends, it's everybody using temp rooms for normal, public RP.
It does feel like a cultural adjustment and I'm kind of feeling out what I think of it. Mostly I feel like it's a work in progress that will evolve.
-
@faraday said in How much Code is too much Code?:
That really works? It boggles my mind that it would irritate anyone any more or less than being sitelocked. Like… you just click the disconnect button? Goes back to: people never cease to surprise in the ways they interact with code.
I know, right!?? Who knew.
You have to feel out the Troll that's attacking, but I find those who go out of their way to get the ban, to the point of even saying they want the ban or the ban is the only way to make them stop, if you stop them by another method, it annoys them to no end.
The person I did this too hated me so much he hunted me down on several servers, just to be able to tell me how much he hated me.
Made my day.
-
@arkandel said in How much Code is too much Code?:
useful IC secrets
<handwiggle>
I drop plot hooks in my RP all the time. I ST. I love to ST. I leave hooks for plots in progress. Fledgling plots. Hooks to things in my character BGs. I run NPCs in general scenes to provide atmosphere and they have hooks dangling, too. Something, anything for people to chase after.
People rarely ever do. I mean, unless you're wanting me to deliver said secret ala hammer straight to the head.
Because, man, you have no idea how excited I got when @scar reacted to the little glowy things I was referencing in RP the other day (@Seraphim73 can tell you >.>). It was an 'omg yes someone is ACTUALLY PICKING UP ON THINGS IN MY POSES THAT CAN CARRY ON TO FUTURE RP YESSSSSSS.'
And I think giving XP/skill progression just for going out and RPing with people is kind of silly. You should want to RP with new people.