@cobaltasaurus said in I made a Python-with-Evennia tutorial (looking for feedback):
@Ifrit helped me figure out the issue, and got me set up with a screen up (derpderp) so I don't have to try and stay permaconnected to the droplet.
Good, then you found out that 'the command evennia is not recignized' is because you've not started the virtualenv in your new terminal. On Linux, using screen is a convenient solution, indeed.
.
Griatch
Yes, it's a fair point, and focusing on a given genre of text game may indeed offer an easier way in for users only interested in that particular genre. If you are planning to offer a web client as well though, I think you'd be wise to make it as easily extendable as possible - the amount of web-dev knowledge out there is so vast that you'll never know what users will want to do with it.
MediaWiki is pretty comprehensive, yes. There are django authentication backends to mediawiki, but I don't know exactly how that works. Here's anyway an example of a running django-driven wiki. It uses Markdown (like musoapbox does) https://demo.django.wiki/ - not as comprehensive as mediawiki + plugins but probably useful for many a use-case (I know we'd not need anything more for Evennia docs at least).
.
Griatch
@Tehom No problem, just thought I'd note down my process - it was not hard but if you are not familiar with Python/Evennia it's easy to get caught up in the details. I don't know if everything actually works as Arx wants it though - if so, do correct me as necessary (it's a wiki after all). 
I've also linked the sources from Evennia's link page.
.
Griatch
Of course they are. "Video game" is just a term for playing a game on a video device - originally a TV, today a monitor. It's very generic and definitely includes text games.
.
Griatch
naybe you are right and we work at different abstraction levels, yes. All Evennia hands over to the command is
cmdnameargs
Where cmdname is the key or alias of the command used and args is everything after it, with no added space.
At least from what I learned about the base "MUX-like" command set we use in Evennia, some 80% of commands can efficiently be parsed hereon by understanding
cmdname[/switch[/switch]...] [arg[;alias]...] [= arg[;alias...],...]
Splitting that into optional easy-to use components make's it easy to do any extra fluff on a case by case basis. As said we have one more base class (inheriting from this one) that also handles commands with syntax for assigning variables etc; but that's basically all we need, and all other default commands in Evennia inherits from this.
.
Griatch
Hi,
I was reading @Arkandel's and others' posts in the Arx thread and the Game Death thread concerning the need and advantages to making it easy for non-staff to run plots. This made me interested in what kind of tools, information, resources etc you look for in a game in order for you as a non-staffer to feel comfortable/willing to run a plot the way you like it.
Coming from the Evennia side, I'm not overly familiar with the various MUSH terminology - so if you love a particular tool or concept, a brief mention of how that tool is meant to function or what the concept means would be appreciated for context.
.
Griatch
@faraday said in Brilliant Breakthroughs and Impossible Projects:
@Griatch said in Brilliant Breakthroughs and Impossible Projects:
Splitting that into optional easy-to use components make's it easy to do any extra fluff on a case by case basis.
Yeah definitely different layers of abstraction. The Ares engine does similar parsing to what you're talking about. crack is for figuring out
args. So you just leave that up to individual commands to figure out, splitting the string as needed? Nothing wrong with that, btw, I just codified that as a separate step.
In principle every individual command class could exactly control it's own parsing, yes. In reality commands end up being parsed so similarly they all inherit one or two parsers with only very few requiring individual extra parsing on top of that.
.
Griatch
@Apos said in Necessary tools for running plots as a non-staff player?:
Yeah, I think we'd need to have something that wouldn't be able to get hung up and just sit there for forever while a half-dozen players are waiting for stories to go on. Which probably mean going immediate to players that can answer it, with the potential to be escalated to staff if needs be, rather than the reverse. The trick there, from a macro perspective, is making sure that things don't have contradictions or continuity breaks that can force the game into changing into a sandbox due to a lack of staff oversight- but even though that's something I wanna avoid it is definitely the lesser of two evils than plot just dying because it can't move forward at all.
Yes, my first thought when reading the original suggestion you wrote was essentially the same as @arkandel's - "that seems like it would be a lot of work for staff". Balancing player-ST agency versus retaining some control over game plot quality is a potentially tricky problem ...
Having a system where players/STs could, with a special command or tag, escalate certain things to staff if they deem they are stepping into parts of the lore they don't know about sounds like a pretty decent half-way solution. Depending on how restricted the setting is and how often such escalations would happen, obviously. Being able to easily get back previous replies to quickly respond to similar-sounding requests from different players sound like an excellent time saver. I keep feeling there should be some sort of automatic mechanic here as well though, to avoid lockups.
Regex-based auto-replies is a good idea but maybe hard to regularize. Another idea may be to have a policy of default timeouts from staff replies. If an ST escalates a request to staff and staff doesn't get back to it in due time, the timeout will auto-reply to the ST that no information was found. A more extreme policy would be an auto-reply telling the ST that they can now make up the answer on their own since staff haven't fulfilled their end by replying in a certain time ... maybe that would put more stress on staff, but it would avoid bottlenecks on that end at least.
.
Griatch
@HelloProject That's awesome! Our current plan for expanding our web client gui is found here in our wiki if you hadn't seen it yet.
.
Griatch
@Apos said in Necessary tools for running plots as a non-staff player?:
I see what you mean, I guess if one codified the overarching metaplot enough - into locations, characters as well as critical story elements like "the plague" or "The murder of X" one could track their use using such a system.
So to follow the VCS analogy, do I understand you right that people sort of "check out" story elements that they intend to use in their plots and "merge them back in" once they are done? With the added feature (going beyond VCS) that people could also find out what is "checked out" at any given time ...?
.
Griatch
@Thenomain said in Necessary tools for running plots as a non-staff player?:
@Griatch said in Necessary tools for running plots as a non-staff player?:
@Apos said in Necessary tools for running plots as a non-staff player?:
@Arkandel Yeah I agree 100%, I mean if a tool is too complicated then at best it won't be used, at worst it'll discourage people from not even trying to PRP since it'd turn them off from it.
It sounds like a prime candidate for using EvMenu actually.
.
GriatchDo you have any links to same? Thanks.
Yes, sorry - EvMenu is the name of Evennia's in-game menu builder tool: https://github.com/evennia/evennia/wiki/EvMenu . People use it for everything from NPC communication trees to character generation, custom login menus and other in-game interfaces.
.
Griatch
Web play is the future for the medium overall IMO, not only because for catching new players but because of the abilities it offers you as the game runner to have a client you control, so to speak.
As for Evennia, we plan to gradually be expanding our default telnet-like HTML5 webclient. Our discussion for the new GUI is here for those interested.
.
Griatch