facundoolano / advenjure Goto Github PK

i.e. "I don't think so", "not a good idea", "mmm"

some variants I can imagine:

• say them in order, and just repeat the last, when all are done
• say any of them randomly (maybe if a set?)

ideally after #16 so the code can be followed from the repl

1. introduction and concepts
2. the simplest possible game
3. the simplest possible game with a puzzle
4. more items and verbs examples (appendix, item/room kws)
5. run in the browser
6. post and pre condition customizations
7. custom verbs
8. dialogs
9. plugins
10. prompt verbs
11. internationalization

I'm really enjoying creating a geocaching adventure app using this engine!

But I think I'm looking for a feature which doesn't currently exist. I want to write logic which depends on the state of the game. As a concrete example, the player should not be able to head to a new location ("room") until they have read a note with the coordinates written on it. I think that I could make this work using the events in the advenjure.dialogs namespace (such as set-event, event?, not-event?, etc), but I think that I would be abusing this feature, as it's specifically tied to dialogs.

Or am I just confused about the correct approach to doing this?

currently Item and Room are records, check if there's a good reason for them not to be just maps.

If they are not needed, remove them (and remove the register-tag-parser from ui.input.cljs

at least at the beginning

basically text that requires pauses I guess

Found an issue on GitHub pages:

If you use height: 100% and padding you need to use box-sizing as well. Otherwise, the element will be bigger than 100%. So in result, you have scrollbars always visible.

Could be useful validations of the basic types (items, rooms, etc.)

Probably a good idea to wait for the api to settle before doing this (e.g. #45)

react to hint/think verbs, some sort of what to do next kind of thing

Hi! I really like this project (even though I almost don't know Clojure) and I had some fun using it already. However, there are two things I missed. Maybe the are already present, but I couldn't take that from example game:

1. Custom commands, i.e. push button or pull lever (maybe even move desk, but that's probably another story). They would for example open doors or simply print some messages.
2. Interactive object where player would need to provide some text from keyboard, for example PIN to ATM or password to the computer, based on some clues around. This could also be a dialog option (say password to a doorman etc.)

So, is it possible to achieve those with current state of engine? If not, do you perhaps have some roadmap on which they are 😉 ?

Anyway, thanks for your effort and publishing this project!

this issue is bigger in clj, remember in cljs the game runs in the browser so the terminal taken problem does not exist.

Still targeting both, if we fix this the clj version may make more sense for development.

• look into proper fighweel workflow. try to preserve game state instead of restarting when code updates
• run game or parts of it from REPL (exit dont kill process)
• add debugging capabilities to a running game, for example print game map (all or specific parts) at any moment
• develop/test from the repl

example: if something needs to be unlocked, how to be sure if it has been tried with the proper key object and not another.

I've commonly seen a bug in opening stuff with any key

which would require to polish docstrings everywhere

A verb spec flag that instructs to use another verb instead, i.e. unlock is the same as open for a safe. Could be as easy as having a kw value: {:unlock "No way" :open :unlock}

there should be a way of porting the clj ones and run both in travis

The engine was written for Clojure because that was what I was learning at the time, but it feels like 99% of the time a user of this library will want to target primarily or exclusively the browser, because who wants to install clojure and play from the terminal?

Even while the conditional code was reduced a lot, removing reader conditionals in the requires alone would improve the readability of the code a lot.

Also, the project will become simpler and development process easier; I imagine new opportunities for improvement will become apparent once we start targeting a single host.

Obviously, unit tests and a better development workflow (i.e. better hot reloading without having to restart the game, fix whatever makes the figwheel repl unresponsive from time to time, etc.).

If you are reading this and think dropping terminal support is a bad idea, please chime in!

Probably because of jcubic/jquery.terminal#39

I'm partially blind and this font is tiny.

the :help values in the verb maps should be used to generate the output of the :help verb

this would most likely initiate a dialog

only for clj version

https://github.com/web-mech/badwords

could work as a plugin

That's the common sign in English, instead of the long dash used in Spanish.

it always show as ?. Need to use eval-direction-sync instead of eval-precondition

_get and _set in map. See how to exclude from suggestions

i.e shift+up = north

for example crowbar + door needs to react to all possible doors in crowbar and react in every door to crowbar, with the same text.

https://gist.github.com/mfikes/3e399ede6edd71c2e748c0da3f213bb7

In most cases it's used to eval symbols, which can be replaced by (deref (resolve s))

If we successfully remove eval then advanced optimizations for cljs could work again.

A lot of code has been rewritten since the en-present and es-past dictionaries were first defined, so some keys are wrong and a lot missing. Scan the files and generate new dictionaries.

I'm having some odd behaviour with figwheel where it appears to be actively undoing changes to my src files

it's annoying and never useful

maybe add a helper function that adds a unique id to both

only in browser

This:

(def living (-> (room/make "Living Room"
                           "A living room with a nailed shut window"
                           :initial-description "The living room was as smelly as the bedroom..."
                           :synonyms ["living" "livingroom"])
                (room/add-item drawer "There was a chest drawer by the door.")
                (room/add-item door "")
                (room/add-item glass-door "")
                (room/add-item portrait "A portrait ocuppied a very prominent place on one of the walls.")
                (room/add-item (item/make ["window"] "It was nailed shut." :closed true :open "It was nailed shut.") "")))

Should turn into this

(def living (room/make {:name                "Living Room"
                        :description         "A living room with a nailed shut window"
                        :initial-description "The living room was as smelly as the bedroom..."
                        :synonyms            ["living" "livingroom"]
                        :items               [drawer door glass-door portrait
                                              (item/make {:names       ["window"]
                                                          :description "It was nailed shut."
                                                          :closed      true
                                                          :open        "It was nailed shut."})]}
                       :item-descriptions {"drawer"   "There was a chest drawer by the door."
                                           "portrait" "A portrait ocuppied a very prominent place on one of the walls."}))

The reason why a symbol is required is that it would break the save/load serialization of the game state if function values are used instead.

Look into making a serializer that knows how to do it?