WaysToPlay

Ways to Play

There are a bunch of options to play Quest Command. Web is the fastest way to jump in and try it, and Java Jar is the main target.

Android

This version was essentially an experiment and I haven't touched it in years. It most likely won't work.

Clone the repo and build for android. This version includes 'suggestion buttons' so instead of typing commands you can do basic commands by pressing a series of buttons.

I may roll this into the multiplatform version eventually, but don't see myself doing it any time soon.

Docker

Grab the image from docker hub and run docker run -it manapart/quest-command:dev

This image is updated on pushes to master but it isn't frequently tested

Java Jar

The Java Jar is the original and main target. Normally you run it with any terminal you normally use, but you can also run it in a way that it creates its own terminal.

Start by grabbing a release from github and run java -jar ./quest-command-jvm-dev.jar

You could also clone the project and then build the jar yourself (to try a branch or code that's newer than the most recent release).

./gradlew build
java -jar ./build/libs/quest-command-jvm-dev.jar

In your Terminal

Running in your terminal is the purest form of Quest Command. It's the most used and truly has no GUI.

That said, the one and only con of running in your terminal is that I can't provide dynamic autocomplete, which the GUI terminal and web both provide.

In a GUI Terminal

The GUI terminal is nice in that it allows you to autocomplete commands, which can be really helpful to learn commands as you first start, as well as more interactively decide what to do. To play this way, run java -jar ./quest-command-jvm-dev.jar --windowed

Web

The web version has a number of pros and cons over the Java Jar version. You can try it here.

Pros

• Play instantly and easily without a download
• Startup time
• Tab complete
• Play multiplayer against someone hosting a server, just like in the jar version

Cons

• Saving or loading is very slow at the moment as the current web saving is implemented in a non performant way
  • If playing multiplayer, the host server is responsible for save and load
  • There should be plenty of room to optimize web saving in the future
• Reduced performance (shouldn't be noticeable)
• Less tested and polished: when I ported to web some functions needed to be reimplemented in js and may not be one to one to the jar version
• All tests run against the JVM version, so again web specific functionality doesn't have as many grantees

You can also clone the repo and test/run the browser version by running gradlew jsBrowserDevelopmentRun