I certainly think this is would be useful, especially for bringing in new people from outside the hobby. Making a lot of things like chargen and such, web based, removes a lot of barrier to entry in my opinion.
Posts made by SparklesTheClown
-
RE: Separating UX from Functionality (Design Patterns!)
-
RE: How Do I Headwiz?
While I agree with the general sentiments here, I'm not sure if I generally agree with the emotional distance, even the little bit of emotional distance. In general, my experience (which as most people know is, like, a lot of games), staff, especially headwizzes, that presented themselves as this vaguely distant figure, or elevated above or away from the playerbase, were generally difficult to approach and gave the games a significantly different feel than games where staff and the headwiz just seemed like a regular part of the community who were just there to enhance the experience.
Obviously the normal battle scarred player who sees corruption and treachery at every turn is going to think that literally everything is favoritism, but I feel like there's a limit to what you can do about that without just being an unfun robot who is taking their position seriously on a level that I've never found particularly tasteful. Which isn't to say that being a headwiz isn't something to take seriously, but I believe there is a line that changes the tone of the game's atmosphere in a way that I genuinely don't like.
I don't think everyone is going to like you, but like, I think it's important to be your genuine self and not artificially distance yourself from the game or connections. If people genuinely can't do that while simultaneously not walling themselves off into a corner of favoritism and only doing things for certain people, they shouldn't be worrying about artificial distance, they should just straight up not be running a MU, in my opinion.
-
RE: UX: It's time for The Talk
@Sparks I actually had no idea. I thought +mail was just some shit people made up for no reason.
-
RE: UX: It's time for The Talk
I'm just gonna say that I never saw what +mail contributed to anything. It's never been more simple than the hardcoded mail and always just seemed like an annoying new thing to learn. I've yet to see anyone adequately simplify mail in a way that justified having to learn entirely different annoying mail code rather than just keeping annoying mail code I actually know how to use.
I'm not suggesting that I know how to make mail simpler, just not to replace it with something that isn't particularly better and then I have to learn that too.
-
RE: UX: It's time for The Talk
I've been in this hobby for a decade+ and still don't realize there's a far superior +who until like months in, if I'm lucky.
-
RE: Health and Wealth and GrownUp Stuff
I'm currently horrifyingly sleep deprived. I think that's on topic.
-
RE: Toonamu Plans 2017!!! DOCUMENT DRAFT NOW AVAILABLE!!!
This shit is rough, but I came to certain conclusions about progression and the way that I want to run the game.
I honestly realized that it's very, very hard to design narrative consistency and focus into a progression system that is essentially XP. I still like my card idea, but like, I think I might honestly have to compromise and do +requests. It's not as random or even necessarily as fair as I wanted things to be, but like, in designing this stuff, having a totally 100% random progression system is just not really the game I want to run.
In some ways I feel like this is a failure on what I even set out to do, but I feel like I'm realizing more of what I even want out of this project. Like, it started out to prove a point, but as I think more and more about the kind of game I want to run, my original ideas seem like good ideas in the practical sense, but not in the sense of "This would be a fun game for me to run".
I have mixed feelings right now, about my current decisions, but at the very least I feel like they're the ones that'll make me happy with the game. I feel like I can't keep pushing a design premise that I won't enjoy, when I know very well what I would enjoy.
-
RE: UX: It's time for The Talk
Oh, so you're kind of saying what I usually say about designing a game for your audience.
I guess I never thought of it in the context of codebase choice. (Except MOO, fucking MOO)
This is probably a MU challenge I'll have to keep in mind.
-
RE: UX: It's time for The Talk
I guess I keep going at it from the perspective of the coder also making the game.
That isn't my intent, but for some reason that's where my brain keeps going.
-
RE: UX: It's time for The Talk
I'm not saying you aren't, just saying that it's not really a player problem. Players are kind of at the mercy of coders.
The fact that WoD and many other systems aren't made for a MU, is a part of why I'm trying to design my system to be MU specific, even if it's taking inspiration from lots of different things. I think a MU specific system will be an interesting experiment.
It's not like people have never made MU specific stuff before, there's plenty of examples, but I honestly haven't seen progression systems that truly take the long-term nature of a MU properly into account. Like, the best example is XP catch-up stuff. But yeah, WoD is really not made for a MU, and there aren't really ways to get around those problems without WoD just straight up not being WoD.
I realized while designing the progression and combat system of my game that the problem isn't necessarily XP, the problem is actually attributes and the way that these tabletop games look at combat. It's not something I considered until trying to figure out how to avoid power bloat/creep, since common wisdom has always been that XP is the problem.
-
RE: UX: It's time for The Talk
@Thenomain said in UX: It's time for The Talk:
This isn't a coder issue, it's a user issue. It won't change overnight.
Well I mean, you've gotta code it that way for users to get used to it. It has to start with coders, there's literally no other way to do it.
It's not exactly a chicken or egg scenario.
-
RE: UX: It's time for The Talk
@WTFE Seems to be much better at articulating this topic than me.
-
RE: Toonamu Plans 2017!!! DOCUMENT DRAFT NOW AVAILABLE!!!
@Ganymede No I'm saying that's what my system is.
edit: The reason for this system is because I wanted to do away with normal experience and stat progression and find an alternative that didn't lead to inevitable power bloat/creep and alienate newbies.
-
RE: RL Anger
@Meg Your area seems chill, except for the terrifying skyline and being in the middle of no where.
-
RE: Toonamu Plans 2017!!! DOCUMENT DRAFT NOW AVAILABLE!!!
@Ganymede said in Toonamu Plans 2017!!! DOCUMENT DRAFT NOW AVAILABLE!!!:
@HelloProject
I think that is a great idea, actually. I tried to do the same. By narrowing combat to a card or a simple sheet, you could feasibly as a player allow another to control you in a combat that you cannot attend.
Actually, this is more like combat actions and various combat events are handled with cards. The player character is more like what a Planeswalker would be in MTG (they may have special abilities). Though my intent is to not have anything be wildly outrageous, it's more to give a method of growth and combat that gives this feeling of progression and strategy, without it being like "HAHAHA MY PC CAN BEAT ALL THE OTHER PCS!!!"
Though there will be major villains like that, who are meant to be defeated eventually, but be an extremely imposing threat early on. My emphasis is on the things that can be done in combat, and how things interact, rather than purely "This number is higher than that number!", though numbers will obviously be a part of it. I don't want insane power gaps between players, but I want there to be just enough of a difference for someone to be like "Wow I'm pretty awesome since I got this super transformation".
-
RE: RL Anger
@HelloProject said in RL Anger:
... maybe they're the fucking problem with this country as much as any goddamned backwards
redneck.Hey watch that! Only my people can use that word.
Holy shit, thirteen channels of wrestling? Maybe I need to get in on this business.
-
RE: UX: It's time for The Talk
@Thenomain I'm just trying not to seem so much like, uhh, "THIS IS HOW THINGS WORK WHERE I'M FROM", like I used to be on WORA, which is why I was trying to speak to the WoD crowd.
-
RE: UX: It's time for The Talk
@Derp I mean automatically enter initiative when they enter an attack, not everyone in the room.
I was thinking of parties in the factional sense, though obviously that isn't a good idea (actually maybe I need to define some sort of actual party system for my game, since it'll be more open-ended than usual for this type). I guess it would make sense to have people group up before combat. In MUDs this was done with the follow command. Like, follow <name>. If you had three people following each other, they'd all be in the same party. So, if you attacked someone, your enter party would enter the initiative of combat.
I know that on quite a few places, like M3, the old SRT, MCM, Battle Fantasia, and quite a few others, the way that a KO was determined was just your HP hitting zero and it says you're KO'd and you can no longer attack or anything. Though some of these MUSHes had items or character abilities that would automatically bring you back to 1 HP or something, for one last ditch attack.
Either way, I imagine that if you did an actual party system where people are tagged as being in the same party temporarily, then when they enter into combat, anyone who isn't in your party is the opposing party. That seems reasonable. I feel like the only extra step on the player is just using "follow", which is like one extra command, and that's only if they're using group combat. Actually, I'd probably code it more intuitively as "group", because I don't want a follow command working like an actual follow command (no one likes forgetting to unfollow someone and then get dragged like 10 rooms away).
@faraday I think that's all reasonable, especially when you consider that your system is supposed to be universal, and it probably lacks the annoying as shit quirks as the system I described. Like, this makes sense if you consider how GMing might possibly work in a particular game. I've seen games with very elaborate combat systems that are meant to be PVP first and GMing second. So, it depends on the needs, I agree.
-
RE: 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.
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 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.
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.
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.
-
RE: UX: It's time for The Talk
@faraday I feel like I've provided examples all through the thread though, because people have asked me direct questions repeatedly, and I've answered them and even repeated myself in multiple posts a few times.
It's not like I'm holding up MUDs as the paragon of MUdom, I don't even play MUDs anymore for a variety of reasons. The only reason I used them as an example is because they're very good at abstracting insanely complex things and I don't think it's entirely terrible to aspire to that.
That said, the hobby is very broad, and I've played a lot of games and saw a ridiculous manner of dumb shit to the point that, yeah, my main thing is "Hey, can we please keep in mind that maybe we should put accessibility before 'does this work?'".
I once played in a MUSH that imposed an artificial one second lag between each room that you enter, to simulate "travel times". That was the dumbest shit in the universe. I can drop countless isolated examples of eccentrically dumb design decisions, and I think that warning people away from it is not a discussion without merit, because this kind of weird stuff happens all the time. Just because one particular coder wouldn't or doesn't do something doesn't mean that it's not worth discussing stuff that maybe shouldn't be done in the broader scope of things, rather than being like "Well, that's fixed, because I don't do it".