Posts made by Rook

Did Spider ruin it?

I went there one time, and laughed myself out of CharGen due to the 'helpful pages' I was getting about what to make.

@Thenomain said in UX: It's time for The Talk:

p.s., @Rook is a Furry.

@HelloProject said in UX: It's time for The Talk:

@Rook I mean, like for example, and I honestly forgot what game this was, maybe it was more than one? Anyway:

There was a game where you had to join into a combat pool. It wasn't always entirely clear if you were in the combat pool or not, you could actually forget and be in it for days, so combat was not technically over. Everyone being done didn't automatically dump you out of it or anything. There were a few commands involved, I think something like +init to start combat, then I think something like +combat/join to actually join into the combat pool thing.

This by itself isn't particularly a syntax issue (though I still think that these plus signs and slashes need to be burned with fire). But the fact that you need two separate commands to join combat, plus a third command to leave combat that you constantly forgot to even use, so you'd be trying to join a combat situation with someone else and you'd be like "Wtf is even wrong". Then you'd have to go and find the room you were in when you started combat to get out of it, if I recall correctly, some crazy shit like that. Then once you do that you can finally go back and finally enter combat with the person you planned to.

This is like, an example of a seemingly simple thing just gone way out of hand. None of this was even a bug, that was just how the freaking thing worked.

That's a miss on the coder's part. The room, when dropped into combat, should have had an @oleave/@otport set and the player should have had an @omove set to leave the combat.

My solution would have been to just type <attack><target> and have people automatically enter initiative, then have people automatically leave initiative once the opposing party/person is KO'd. Though obviously I'd have a command to leave combat, just in case everyone doesn't get KO'd, or someone leaves combat before getting KO'd.

But what about the children modifiers? This game had no combat modifiers? Where in '<attack> <target>' did they go?

But anyway, the point was that it was needlessly complicated. Obviously this is just one example, but I feel like it's a good example. What makes things needlessly complicated isn't always syntax.

Your example is not needlessly complicated. It's the exact opposite. It's anemic on details.

You are getting nowhere, here, in the quest to provide concrete things that us coders can pick apart and see where we can offer advice on simplification. In fact, there's nothing to pick apart yet?

Another example is how I've seen some games handle descs in the past. Now, I'm personally used to @desc, I've seen easier descing systems and just didn't use them because I'm used to the regular @desc. But I've seen people create a whole thing where you had to enter into a whole, like, weird desc command line and editing the desc was a whole goddamned process, and goddamn if you wanted to write two paragraphs, fucking forget it.

On those games, "@desc me=<blah>" didn't work? If you had been on MUSH/MUX, we could have taught you @edit, or just 'exam me/desc' to copy/paste back into the input buffer.

Actually, I think that desc example might have happened multiple times, and they were all MOOs. In fact, MOOs (the ones I've tried) seem to do incredibly simple things in a needlessly complicated way, and I have no idea why. But anyway, the proper alternative would be literally any sane desc system. Though I do think that desc could do away with the @ and the =, it's not a huuuuuge deal for how simple what it does is.

MOOs suck. I will not speak coding in regards to MOO, lest @Thenomain call me a Furry again.

......wait. Are your examples and the origin of this thread... based on MOOs? Oh god. I need a drink.

To coattail @faraday

If you code something for a game, you should be playing with that very code, as an end-user in a real scene. It isn't for testing, it's for usability, it's for seeing first-hand the clumsiness, the lacking features, the places where you can streamline things.

If you aren't doing that, then you have no business being the head coder on a game. IMNSHO.

@Derp

@Faraday
Shhhh. You've exposed my attempt to bring us back full circle and use the Socratic method to help answer his questions!

Give us some MOCK EXAMPLES of what you are trying to fix vs what you would do to simplify the command, please? See below!

I hate it when I see: +command/action <target>=<modifier> <modifier> <modifier>

I want to see: +action <target>

Put it in that format. SHOW US WHAT YOU PROPOSE. It can be a fake command, even! Show us how to take a complex command and make it simple.

Jesus, you're talking to coders here. Ambigious conversation (words words words) gets you nowhere with us!

"Instead, you come into my house on the day my daughter is to be married, and you ask me to do murder for money."

The point here being that all of this complexity is doable, but it results in complex command strings that have to be input by the player.

In most MUSHes, the players add up all the modifiers OOCly and just add it to the roll. It's easier for them to do that than get the command string right!

Quiet you. I'm making a point here!

To be fair, MUDs are very, very simplistic.

It is a straight (Weapon+Effects) vs (Armor+Effects) mechanic check, there are no situational modifiers. No terrain, no cover, no concealment, no taking-your-time-on-the-shot type modifiers exist in most MUDs.

So yeah, 'attack troll' works just fine. Your attack vs his defense. Subtract HP. Done.

In a MUSH scene, code cannot account for Troll being ducked behind a concrete half-wall and getting defense bonuses from that. Nor can it "tell" that you moved in your pose this round, thus you have a negative modifier to your hit roll. Or that in the last scene, your armor was doused in acid and structurally compromised. STs and players take account of those "small details", and thus a coded +attack is hard to do without lots and lots and lots of that switch/option cruft that you are saying is making things complex.

Try coding a combat system in a MUSH that takes THOSE things into account. I dare you.

Look, as I explained, I spilled something all over that shirt! And I ALWAYS listen to that style of music!

Because no one has coded it so that it can be distributed to the WoD/CoD games that use it?

@Thenomain and several others have done HUGE THINGS for WoD/CoD games out there, and make their code available to games that want to use it. If you were to code up something comparable, easier to use, I am sure upcoming games would be banging on your door.

@Insomnia
Makes me wonder, paranoid, about what they're embedding and need to spread... oh well. Installed anyway!

@Bobotron said in [Original Supernatural/Vampire MUSH] Houses of the Blood MUSH:

but the character is treated as being in XP debt; so they can spend it all, or bank some of it, but they ain't earning any more til that first loan has been paid back.

Holy shit I love that idea.

@HelloProject
I dunno. I disagree with your assumptions above, for a few reasons.

• I don't think many coders switch coding styles based on from-scratch or hacked/piled-on. You code how you code, and if adding functionality to a system forces you to a style, that's one thing... adding switches to a command, for instance.
• I think most coders I know code the commands to conform with the norms of the game, and make them as simple as they possibly can. When you're talking multiple optional switches, and have to resort to a huge regexp system to sort that shit out, it's no picnic. Coders don't just say "What's the way I can make this all-inclusive as fuck" and just dive in. If they do, I'd have to laugh at them and seriously try to show them that planning your crap out before just tackling a single command is totes the way to go.
• Having the skill and flexibility to code from scratch is huge, in my opinion. It's why it's the only way I work. I don't install other people's code, because my style is wildly different, but it's flexible, easy to debug/expand, and heavily documented. Personal preference.
• As for abstraction, there is a line between abstracting and complicating, as you suggest. I don't see much abstraction on games nowadays, for every WoD sphere has their own unique code, and +sheet systems to parse multiple race data tends to be a lot of @switches and so on.

Back to the OP's conversation, as slanted as it might have come off...

Lots of games do small tweaks to things to make stuff look homogenous, as they can. But most games don't know how to dig into big systems like Myrrdin's BBoards, the +Jobs systems, and so forth, to truly rewrite interfaces. Myrrdin's BBoards have been around since before the turn of the fucking century, and (yes this is a peeve of mine) haven't changed in that time. They're great for what they do, don't get me wrong, but come on.

Most games still use SGP and repository packages that are drop-in, tweak and forget... and that is the extent of "coding" on their game. Many games just then do without other functionality because they cannot find (or trust, a whole other conversation) a coder who can create that system in the way that they want it, in the timeframe that they want it.

So game owners settle for what is quick to install, configure and get rolling... because honestly, people just want to RP. Which brings me to my last point: Most people don't care about the code. Believe me. I've spent months building systems that people look at and say "Meh, I'll stick with <old system X>". Why? Laziness/Familiarity - two words describing the same lack of motivation to learn something new.

Go ahead and rewrite systems for your upcoming game, and you'll see firsthand what people are telling you here. Not trying to discourage you, it is a very solid way to deepen your coding skills... but don't do it if you are after praise and recognition. Coding is not for you if that is your goal.

People respond much more lovingly to STs and Sphere Wizzen who directly enhance their RP .... far more than they do to coders that provide the system crunchies to get the business of RP support done.

Now I am very interested in looking at the codebase. Academically, I'd want to discuss your design document, your coding standards, that sort of thing. Establish rules for everything from command structure to help files. But that's a big undertaking, believe me. I've worked with the Rhost team for years, and while I throw all kinds of shit at @Ashen-Shugar as ideas, and most of them get implemented in one way or another, it is no easy task. I watch that dev team hammer through issues both legacy and limitation-related, and I know it's frustrating.

What can seem like a "small thing" to a softcoder can turn out to be spaghetti-code-diving for the hardcoders to fix the issue causing the gap in the first place. This is why I stick with Rhost, because I've watched that team do rewrites of major chunks of code to make it more secure, faster, better and more featureful.