Open blalasaadri opened 5 years ago
Is this something that we would want in an adventure based engine, or should it be a separate component of the game instead?
Is this something that we would want in an adventure based engine, or should it be a separate component of the game instead?
A valid question. The way I see it, the CLI is actually very closely related to a dialogue system (which will have to be supported by the engine). Building both in the engine first will allow us to know, what can be abstracted away in the engine and what is too specific and should live in the game itself.
@blalasaadri Thank you created an issue for this! Yes this is definitely something we'll need and something that can mostly be implemented independent of the game.
@mwcz is working on the Action system that will run the handlers when users click on objects or perform other actions in the game. This will be mapped to tiled properties. The command line system should be able to run actions directly from @mwcz comment in Discord:
"@blalasaadri In the action-example branch you'll find actions.js, which has an eval(...) function for executing commands the only commands currently built into that example are turnon, use, and setsprite but more to come!"
For example if there is a light in the room with a light switch, the player could click on the light switch which would execute the action "turnon light1" But a player should also be able to run that exact same command but from the command line:
[terminal ~]# turnon light1
That would run the action turnon
with the argument light1
also turn on the light.
So to start you can keep it pretty simple, and focus just on the parsing, where the first word is a command and everything after that is an argument.
You could also put some easter eggs for common bash commands ls
or cd
In the game, the player will have to "interface with the ship's computers from within by learning one of the most powerful tools available: The Command Line" (as described in the game readme). What this means is basically:
An example of how this may look is:
There are also several open questions, including:
--room 2
) be allowed or should those always be connected (e.g.--room=2
)?An MVP would be an interface that is:
--room=2
is one argument but--room 2
would be two)bcs --room=2 --device=lamp activate
command may cause the lamp in room 2 to be activated