@Tehom said in Getting Young Blood Into MU*'ing:
@Griatch said in Getting Young Blood Into MU*'ing:
Ditching Commands altogether is not a self-goal in my opinion however. Commands remain in use (also outside of MU*) because they are highly efficient ways to tell the computer (game) what to do. Some things can be offloaded to buttons in a GUI, and that could get you some part of the way, but only for very simple inputs without arguments. Trying to replicate complex command functionality with a GUI will quickly build up complexity in that domain instead.
I'd agree with this, but I think what might be a good evolution in the far future is to make commands into very thin text interfaces for model methods/utility function calls, which would then be accessible by web interfaces. Text commands are largely analogous to text-based Views that perform some task and output text, and ideally they'd be solely responsible for validating input and presenting text output, where all the real meat of what's being accomplished is handled elsewhere and could be called independently by whatever - text commands, web views, RESTful API calls, celery tasks, scripts, etc. You could even have shared validation by using serializers/forms in both for a very DRY approach, but would sadly greatly increase the barrier to entry.
I think the notion of being able to call a Command through any client input or API call is a good one. Unless I completely misunderstand what you mean it's however also already something Evennia supports out of the box. What we don't have today is the REST API endpoints themselves, but the REST API would just be another authenticated client input in this case - same as telnet, webclient or ssh.
The input from whatever client (in Evennia known as the inputfunc
) is already today completely generalized and could come from wherever client - like a telnet connection, GMCP/MSDP or a JSON blob from the webclient or an optional REST API. Once parsed by the wire protocol, the inputfunc looks the same to the system, regardless of source.
The parsing of the text
inputfunc (which is the Evennia name for the In-band instructions we write on the command line) is not 100% up to each individual command class, that's true. But honestly, it's not far from it - all Evennia does outside the Command class is to figure out which command class to call. From there on, the parse
method of the Command class is responsible for all parsing of the command's arguments. Through class inheritance you can have many Commands share this parse functionality, but you could easily make each do its own if you wanted to. I think it's pretty hard to imagine a more general system while keeping Commands as separate entities.
Could you elaborate on what you think should work differently (apart from adding a RESTful API as a new input in the first place)?
.
Griatch