when door is opened with key, door is still closed in description about breakoutbot HOT 5 OPEN

Thanks for the issue, @tmbo will get back to you about it soon!

You may find help in the docs and the forum, too 🤗

from breakoutbot.

Part of what is happening here is that the game is missing an endgame. We've only implemented the bare-minimum for now and there's no mechanism to notify the user that they've completed the game.

There's also a bug in the key/door mechanic at the moment #3

from breakoutbot.

You are aluding to a "bigger" issue to our "game engine" though. The way the slots are currently implemented are relatively basic. Eventually we'd like to go a step further and something that is more configurable.

What I'm currently thinking of is to have some sort of file, ie; game-objects.yml that has information like;

- name: key
   info: It may just be "the key" to getting out of this room. 
   pickup: 
     - able: true
     - message: That key should fit in my inventory. Easy. 
   visible: false
- name: box
   info: It's a cardboard box. There's two items in it. There's a key and a poster. 
   pickup: 
     - able: false
     - message: I don't want a cardboard box.
   visible: true

The idea here is that a custom action can change the state during the game by changing the information listed here. The visible property can be turned to true for example only after you've looked at the box. We can also change the description text in a similar way.

This is an idea I've been toying with but I've not started implementing this. It seems like something I'd need to build via unfeaturized slots and I'll need to explore how flexible this is.

from breakoutbot.

What you're describing sounds like a good idea. Maybe you could put it like this:

- name: door
    info: The door is locked.
    ...
    action:
        - done: false
        - required_item: key
        - info: The door is open.

I don't know if this makes sense :) but I will also continue in researching around this topic 😁

from breakoutbot.

There's a similar issue that we'll need to adress with the cardboard box. Once somebody takes an item out of the box then the text you read when you "look" at it needs to reflect that. I don't know what a nice balance to strike is here and I imagine that the only way to know for sure is to "try it out".

One design preference on my side is to seperate concerns such that game-objects.yml represents all the state of the game and that actions.py describe all the changes that could happen to that state. By keeping these concerns seperate I imagine this project will remain easier to maintain.

In terms of planning, I'm getting married this weekend so it might be another week or two before I will be able to properly dive into this 😅. @LarissaHa if you end up playing around with this, feel free to let me know any lessons learned here.

from breakoutbot.