@Groth said in Getting Young Blood Into MU*'ing:
@Griatch said in Getting Young Blood Into MU*'ing:
Yes, I know well these techniques, and as said all of them are available as stateful commands or even as ready infrastructures like EvMenu in Evennia. These have no problem with REST, they are saved to the database. If necessarily wanting to go the room-based chargen route you can of course have commands on rooms in Evennia too (but personally I find it ugly to use rooms to mimic what can be handled by a proper multi-option menu ... but I digress).
The point about rooms is that they're the simple way to do things. I think it's unhelpful to someone who wants to develop a game to give them shortcuts that they'll regret later.
A room is simple sure. If there is a story/tutorial/aestetic reason to use rooms for the chargen, go for it. Not using in-world entities (like rooms) to describe and code out-of-world actions (like chargen) is my personal preference.
I think Evennia Attributes are an example of this because they might look really tempting and easy to use when someone is starting out, but later when they come further trying to design their game systems and maybe want to migrate their database they'll come to the realization they need to rewrite everything because attributes are kind of awful when you actually try to do anything with them.
It sounds like you are talking from experience here, have you run into this situation with your game design?
(For those reading this and not knowing what we're talking about, Evennia Attributes allows you to associate an arbitrary piece of data to an object and then use it from there. The boon is that it will be stored persistently in the database for you behind the scenes so you don't need to worry about it. It makes for a powerful way to group and organize persistent data. Here's an example of assigning stats to a character object:
character.db.stats = {"HP": 10, "MP": 12, "SP": 8}
stats = character.db.stats
hp = character.db.stats['HP']
character.db.stats['HP'] -= 1
Attributes are excellent for organizing data but they are not suitable for all things, particularly larger structures that you may want to query in the database later. So, to use the above as a (contrived) example: if it's important for your game design to find out which of the characters across your entire game that has below 5 HP, then querying the database for that will be less efficient if Attributes are used (basically since a generalized structure like this cannot be search-optimized in the database as well). For the same reason, making a BBS system or Mail system where each mail is an Attribute will likely be less efficient - and for this, you may want to make a new database model instead; that is, a new db table with specialized columns for exactly what you want a mail or BBS post to be. This scaleability is what I presume @Groth refers to.) That was the longest parenthesis I've done in a while.
I think it's better in cases like that to simply give people an entirely non-code way to handle things. Already in the 1980's we made a distinction between coders and builders and I think that's the right way to go.
Ok. I personally prefer to make things in code - it's much faster and much more powerful than relying on an intermediary builder-layer. The drawback is of course that you need more of a technical background and knowledge of the library resources. Hence we do supply builder commands out of the box.
Evennia is a programming library, first and foremost though. A developer is welcome to build whatever build commands and structures they want to make things easier for their builders.
That said, I'm not at all averse to adding more builder resources to the Evennia distribution, we are actively trying to do so in fact - as optional contribs.
Instead of giving people shortcuts to code menus and text adventures, why not straight up give them tools to generate menus and text adventures?
This sounds like a tautology to me. What you describe as "Shortcuts to code menus and text adventures" are the tools to generate menus and text adventures. Don't confuse non-code building with tools not being available. The two have very different audiences.
If you look at various game dev toolkits, they're usually some kind of simplified scripting interface available designed to make it easy for people who don't know how to code to make things happen.
So softcode? Or are you more referring to a point-and-click thing? Edit: Reading on, it appears you are. 
You could argue that the first 'code' I ever did was messing around with the Starcraft map editor.
It shouldn't be that hard to make a web interface for Evennia to allow people to make Zork style adventures without ever having to touch python.
I wouldn't say that. Don't underestimate the complexity of Zork and other IF games. Consider Quest, which is an engine point-and-click way to make IF games in your browser (I made this many years ago in it) - it is solely focused on this style of gameplay, has lots of resources and still, trust me - I really wished for the ability to fall back to code to do what I wanted. Non-coded creation is simply very hard to make flexible enough; there will always be things you didn't think about that the dev wants.
But sure, a simpler Zork-style web creator would make for a nice contrib.
I don't mind learning the different stuff. My thing is more 'how much of a learning curve is customization going to be', which also isn't a big deal either way. Just trying to get a handle on expectations.
