Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create the command line interface system #47

Open
blalasaadri opened this issue Dec 5, 2018 · 3 comments
Open

Create the command line interface system #47

blalasaadri opened this issue Dec 5, 2018 · 3 comments

Comments

@blalasaadri
Copy link

blalasaadri commented Dec 5, 2018

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:

  • under certain conditions (maybe always, maybe only when the player is in a certain state, e.g. in a specific room) a command line interface will be visible
  • this interface will have to accept text input and be able to return text output, similar to e.g. a terminal running Bash.
  • it has to be possible to define commands that the CLI will recognize, including
    • the command itself
    • possible arguments
    • a white- or blacklist for when the command can be used
    • the output of the command (which may depend on the arguments)
    • effects to the game state, that running this command will have (depending on both the current game state and the given arguments)

An example of how this may look is:

There are also several open questions, including:

  • should the user be able to edit text files? If so, a navigation within a 2D environment (the text file) is required.
  • should there be a history of previously called commands? If so, how many commands should be saved in the history at any given point in time? (e.g. the last 5 commands)
  • should tab completion be available?
  • should arguments be possible in any order?
  • should combined arguments with spaces (e.g. --room 2) be allowed or should those always be connected (e.g. --room=2)?
  • should any kind of scripting be allowed? (e.g. branching, loops, pipes, ...)

An MVP would be an interface that is:

  • always visible to the player
  • accepts text input
  • recognizes commands
  • recognizes combined arguments (so --room=2 is one argument but --room 2 would be two)
  • allows the definition of output which may depend on the arguments
  • allows limited game state changes (e.g. calling the bcs --room=2 --device=lamp activate command may cause the lamp in room 2 to be activated
@steaksauce-
Copy link

Is this something that we would want in an adventure based engine, or should it be a separate component of the game instead?

@blalasaadri
Copy link
Author

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.

@Jared-Sprague
Copy link
Member

@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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants