Optional Realities & Project Redshift
-
@Jaunt I like the concept of the command-less emote with
@in it. Is this just a random example idea or something you are actually planning/have made for Redshift?
.
Griatch
(who recently made a contrib emote system for Evennia but used the "emote" Command and didn't consider making it as a "no-match" system command. Cool idea!) -
@HelloProject said:
And rather than paying for server space, you simply hosted the server on your own computer.
I would think this is possible with any game server though - if you accept the electricity bill and has the Internet connection for it?
.
Griatch -
@Griatch said:
@Jaunt I like the concept of the command-less emote with
@in it. Is this just a random example idea or something you are actually planning/have made for Redshift?
.
Griatch
(who recently made a contrib emote system for Evennia but used the "emote" Command and didn't consider making it as a "no-match" system command. Cool idea!)Our idea for Redshift is to try to parse all possible output for to-the-room roleplaying tools using @ wherever possible, yeah. We have a stock RPI-ish system similar to your recent Evennia contrib in place currently, for the purposes of testing. Our goal is to have our fully realized system in place for our engine/game DEMO in the Spring. : )
@HelloProject said:
Once one gets used to the hobby itself, and perhaps gets a taste for wanting to do something more complex, if they do at all, then they can move onto learning an established thing like Penn. But again, as long as it costs money to make a MU*, I think that's going to remain off-putting.
Well, I don't think that streamlined design needs to be any less complex in terms of functionality. In fact, REDSHIFT's really rather super complex in terms of what's possible. My goal with it is to make it easy to learn the basic commands (roleplaying tools, navigation, combat, etc) so that there is a more organic learning curve for new players. It's not about removing complex options, but rather making them easier to use.
As far as hosting goes, it's actually really super cheap. @Jeshin pays about $200/year for REDSHIFT's server and three different websites with full forums and other features. The real cost for creating a MU* is in time -- specifically the developers'.
-
@HelloProject said:
edit: Byond Tabletop allowed you to customize a sheet for people to use, with a shitty version of HTML. You could create different rooms and stuff. And rather than paying for server space, you simply hosted the server on your own computer.
There has never (not even in the dawn of internet) existed a technical restriction that required you to pay for server hosting rather then hosting it yourself. The reason to purchase hosting rather then host yourself have always been the same.
- It's usually cheaper to purchase a hosting service then pay the electricity bill of keeping a computer on 24/7.
- It's hard to maintain a good service availability at home between power outages, network disruptions etc.
Minecraft is a really good illustration here. It's utterly trivial to host your own minecraft instance however the virtual hosting providers are ungodly popular because they're really cheap and really easy to use with one-click installs for all common configurations.
The reason you're not going to see 'Babys first MU*' is because unlike Minecraft, you can't really start a MU* by just starting the server configuration of your choice and press 'Go'. After you've put your server online there is a metric fuckton of work awaiting you in making that server into an actual game anyone would want to participate in in digging a grid, writing a rule-set, writing a theme etc etc.
And if you're not going to use a grid and custom built-in rules, it's hard to justify using MU* software over just IRC or Skype.
What is obvious to you may not be obvious to me and vice versa.
-
@Groth said:
@HelloProject said:
edit: Byond Tabletop allowed you to customize a sheet for people to use, with a shitty version of HTML. You could create different rooms and stuff. And rather than paying for server space, you simply hosted the server on your own computer.
There has never (not even in the dawn of internet) existed a technical restriction that required you to pay for server hosting rather then hosting it yourself. The reason to purchase hosting rather then host yourself have always been the same.
- It's usually cheaper to purchase a hosting service then pay the electricity bill of keeping a computer on 24/7.
- It's hard to maintain a good service availability at home between power outages, network disruptions etc.
Minecraft is a really good illustration here. It's utterly trivial to host your own minecraft instance however the virtual hosting providers are ungodly popular because they're really cheap and really easy to use with one-click installs for all common configurations.
The reason you're not going to see 'Babys first MU*' is because unlike Minecraft, you can't really start a MU* by just starting the server configuration of your choice and press 'Go'. After you've put your server online there is a metric fuckton of work awaiting you in making that server into an actual game anyone would want to participate in in digging a grid, writing a rule-set, writing a theme etc etc.
The average RPer is not going to have any idea how to get a modern MU up and self-hosted (Hell, the average RPer is not going to know how to get a MU hosted at all). And stuff like digging and all of that are still not particularly streamlined or intuitive unless you're already used to it. There needs to be something even simpler than softcode, and I have to entirely reject the idea that it isn't possible.
There's absolutely no reason that one shouldn't be able to quickly build their grid and theme without having to sit down and learn a bunch of code first, soft or otherwise. And no, hosting a server yourself isn't going to be perfect, but this is -exactly- how Byond works and I already have an idea of the pitfalls of players hosting a game on their own computer.
It's not a big deal and games go down. When someone decides to really commit, they might find cheap hosting, they might not. But actually hosting is an option and it's super easy. Of course Byond itself has its own programming language, so it wasn't particularly easy for non-coders to make a game, and they stole code a lot >__<.
But either way, if creating a simple package to create a MU without knowing any sort of code is not seen as viable by MUers themselves, I guess I'll have to make it a future project myself. It would make sense for me to do it anyway, since I already have a clear idea of the scope of what RPers outside of MUs would want anyway.
The idea that people need to pay their dues or whatever and learn to code just so they can create a MU is a ridiculous barrier to entry, and a part of why our community isn't as large as other RPing communities. Creating a simple package and throwing it out there to be used doesn't hurt anyone, so I'll make it my own pet project.
-
@HelloProject
What you're suggesting is actually the purpose of another really cool project (that's on a 9-month hiatus due to 9-month reasons right now):
I know that the goal is to create an engine that is super easy to get moving and requires minimal amount of programming knowledge to use.
Evennia, while it does require programming knowledge, does make things easier with its clean code, interface, support community, excellent documentation, and its use of Python. It's pretty easy to get Evennia running out of the box. As more contribs are open-sourced, eventually plug-and-play modules will hopefully make it pretty quick to get a fully functional game going. I know that we aim to do this for Evennia with our modules once we've got a basic, usable, adaptable engine and modules prepared.
Hopefully in the next year, folks will have some great new options to start a game with less obstacles.
So, those sorts of projects that you're wanting do exist. They're just still developing. They could be used to create a MUSH-like or RPI-like or any other sort of game, ultimately. The idea is flexibility and modularity, for both projects.
-
@HelloProject said:
The idea that people need to pay their dues or whatever and learn to code just so they can create a MU is a ridiculous barrier to entry, and a part of why our community isn't as large as other RPing communities. Creating a simple package and throwing it out there to be used doesn't hurt anyone, so I'll make it my own pet project.
Do consider dropping into the #evennia development IRC channel on Freenode. Would like to hear more what you had in mind. Maybe we can help each other out!
.
Griatch -
@Griatch said:
@HelloProject said:
The idea that people need to pay their dues or whatever and learn to code just so they can create a MU is a ridiculous barrier to entry, and a part of why our community isn't as large as other RPing communities. Creating a simple package and throwing it out there to be used doesn't hurt anyone, so I'll make it my own pet project.
Do consider dropping into the #evennia development IRC channel on Freenode. Would like to hear more what you had in mind. Maybe we can help each other out!
.
GriatchI'm still learning, to be honest. I was going to use this as both a learning experience -and- a productive contribution. That's the only reason I haven't really been involved in Evennia. But I will drop in, maybe I can learn something.
@Jaunt Future MUD looks -very- interesting. I'll do some reading into that too.
-
@HelloProject said:
There's absolutely no reason that one shouldn't be able to quickly build their grid and theme without having to sit down and learn a bunch of code first, soft or otherwise. And no, hosting a server yourself isn't going to be perfect, but this is -exactly- how Byond works and I already have an idea of the pitfalls of players hosting a game on their own computer.
I don't think it's possible to make digging any easier then it already is in most MU* while still using a CLI interface. There are all sorts of benefits that could be realized by creating a system with a graphical interface instead but that's a huge undertaking.
What is obvious to you may not be obvious to me and vice versa.
-
@Groth said:
@HelloProject said:
There's absolutely no reason that one shouldn't be able to quickly build their grid and theme without having to sit down and learn a bunch of code first, soft or otherwise. And no, hosting a server yourself isn't going to be perfect, but this is -exactly- how Byond works and I already have an idea of the pitfalls of players hosting a game on their own computer.
I don't think it's possible to make digging any easier then it already is in most MU* while still using a CLI interface. There are all sorts of benefits that could be realized by creating a system with a graphical interface instead but that's a huge undertaking.
There are a million ways I could think of making digging easier that don't involve a GUI. But being used to doing things a certain way can make it seem so easy that one can't possibly imagine how it could become easier. I mean, look at the average MUSH chargen vs. the average MUD chargen.
The average MUD chargen prompts you for questions, then prompts you for a desc and background and you're done. Someone just needs to look at you.
The average MUSH that doesn't work based on email apps, often involve using a bunch of different commands and having to look at documentation, because often it's not entirely clear how to use the commands.
I'm not saying that one is better than the other, but MUD chargens are usually way simpler than MUSH chargens. They practically hold your damned hand through the entire process.
Obviously I'm not debating chargens, I'm simply comparing the two things to show how different they are in levels of simplicity. Things can -always- be simpler.
-
@HelloProject
The basic @dig command in Pennmush works like this
@dig Kitchen
This command will create a new room named 'Kitchen'. You will be informed what the dbref of this room is.
@dig Kitchen=Kitchen <N>;n;north;kitchen;k
This will create the room as above, and also open an exit leading to it named "Kitchen <N>" with the aliases n, north, kitchen and k. It will NOT create an exit coming back from the Kitchen room.
@dig Kitchen=Kitchen <N>;n;north;kitchen;k, Out <S>;s;south;out;o
This will do just the same as the above, except it will also create an exit named "Out <S>" with the aliases s, south, out and o coming back from the kitchen to whatever room you are currently in.
I honestly can't think of a basic digging command that is simpler then @dig.
@HelloProject said:
The average MUSH that doesn't work based on email apps, often involve using a bunch of different commands and having to look at documentation, because often it's not entirely clear how to use the commands.
I'm not saying that one is better than the other, but MUD chargens are usually way simpler than MUSH chargens. They practically hold your damned hand through the entire process.
Keep in mind the main reason most MUSH chargen is complicated is because they're close adoptions of TT RPG systems which were never designed to be used that way.
What is obvious to you may not be obvious to me and vice versa.
-
@Groth said:
I honestly can't think of a basic digging command that is simpler then @dig.
@dig Kitchen as north to here
-> @dig Kitchen=Kitchen <N>;n;north;kitchen;k,Out <O>;out;o;leave;exit@dig Kitchen to here as Main Room
-> @dig Kitchen=Kitchen <K>;kitchen;k,Main Room <MR>;main room;mrSo yeah, I can.
I don't know what we're talking about or why it's important, but user interface can always be simpler than a string of colons with a sneakily hidden comma.
-
I personally find attempts to use English grammar-like syntax in CLI commands only make them even more hard to remember and type in properly.
What is obvious to you may not be obvious to me and vice versa.
-
@Groth said:
I personally find attempts to use English grammar-like syntax in CLI commands only make them even more hard to remember and type in properly.
The fact that you have to remember any syntax at all pretty much illustrates my entire point.
-
@dig Kitchen/North=here
@dig Kitchen=here/Main Room -
@Thenomain said:
I don't know what we're talking about or why it's important, but user interface can always be simpler than a string of colons with a sneakily hidden comma.
The comma in the pennmush dig command isn't actually sneakily hidden. The syntax is @dig <Room Name>=<Exit Name><; delimited list of aliases>COMMA<Return exist name><; delimited list of aliases>.
That is if you don't want to define any aliases, it's just:
@dig Kitchen=North,SouthHowever if you don't define any aliases, it's unlikely to work the way you want it to work, ergo the more complicated command.
@HelloProject said:
The fact that you have to remember any syntax at all pretty much illustrates my entire point.
By definition you always have to remember syntax when dealing with a CLI interface.
What is obvious to you may not be obvious to me and vice versa.
-
@Groth I guess I should say complicated syntax, then. But either way, an extremely simplified dig command would be:
dig
And then prompts pop up asking what you wanna do and what to type in to do it. Preferably something like north/south/west/etc. Then prompts like what you want the name to be, etc. Dig would initiate a series of prompts, so the only thing you'd need to remember is to type dig to begin with, and everything else is just handed to you.
-
@Groth said:
The comma in the pennmush dig command isn't actually sneakily hidden.
From a coder perspective, no it's not. From a legibility perspective, ;;;,;;;; it is. I'm approaching whatever your 911 is from the claim that you couldn't make it simpler. You can. Part of making it simpler is to make it easier to see what you're doing. Kill that comma.
-
@HelloProject said:
@Groth I guess I should say complicated syntax, then. But either way, an extremely simplified dig command would be:
dig
And then prompts pop up asking what you wanna do and what to type in to do it. Preferably something like north/south/west/etc. Then prompts like what you want the name to be, etc. Dig would initiate a series of prompts, so the only thing you'd need to remember is to type dig to begin with, and everything else is just handed to you.
I think the main reason there's not more prompts at least in PennMUSH is because PennMUSH does as far as I'm aware not have any real support for prompts. Having back-end support for prompts would help a lot in that regard.
@Thenomain said:
@Groth said:
The comma in the pennmush dig command isn't actually sneakily hidden.
From a coder perspective, no it's not. From a legibility perspective, ;;;,;;;; it is. I'm approaching whatever your 911 is from the claim that you couldn't make it simpler. You can.
Yes, a long @dig command is a proper nightmare to read. However it's really easy to write if you understand the syntax which is the point of it, making it easy to dig rooms. In order for the command to work in needs two different delimiters, I suppose you could make it more legible by using |,>,], } or / instead of their choice of ;/,.
What is obvious to you may not be obvious to me and vice versa.
-
@Groth said:
However it's really easy to write if you understand the syntax
"It's easy, once you know how."
This undermines the idea that it can't be simpler. Simplicity compliments flexibility. Flexibility does not compliment simplicity, unless we're talking about redundancy then (through some irony that works) it does.
Which is to say: I think you're trying to push an agenda. Enjoy!
