ethan-bierlein / cactus Goto Github PK

This would allow the user, once they set the PYTHONPATH, to do this:

import cactus.game
import cactus.map
import cactus.position

my_game = cactus.Game(data)

Then, we could also do stuff like this later:

import cactus.color

print(cactus.color.red + "This is red!")

We need to validate class_data in all three classes:

• During __init__
• Every time it's changed

We need to make sure:

• Everything that's required is there
• Nothing extra is there
• All of the items are of the correct types (key and value)

The first one is easy to do, but how do we do the second one, especially when data could change mid-function? Too bad we couldn't "watch" the dictionary for any changes.

This is the reason why I wanted the __init__ argument to be a dictionary, but it actually stored as the actual variables

PEP8 doesn't say.

https://pypi.python.org/pypi/colorama

To make everything streamlined for the user, we should also define all of the colors ourself... somehow. Whoever can find a way to do a syntax like Backgroud_Color.Red please take this issue.

I don't want the user to have to deal with colorama itself because it's not as streamlined. I want everything the user needs to be in Cactus itself

General Convention:

• Leading underscore indicates that you shouldn't mess with this item in this class (equivalent of private)
• No leading underscore says that it's [somewhat] safe to mess with

Exceptions happen in code. Often.

We don't want to spew this data at the user's face, so exceptions would be a good idea.

Having a unified exception "type" would be good for this so the user can catch these (I'm not sure much about Python exceptions)

Should we also log exceptions to a file? Tell the user that something bad happened internally? What?

We need to make sure that the links between the rooms are valid.

We should validate the user's input in MainGame.__init__().

We currently require a ton of nesting to make stuff somewhat readable

Even a simple "map" is really hard to read:

GAME_MAP = GameMap([
    MapPosition(
        "Start",
        "Welcome to the start!",
        "Now leaving the start.",
        {
            "left": 1,
            "right": 2,
        },
    ),
    MapPosition(
        "Left",
        "You took the left path and died.",
        "",
        {},
        function=exit,
    ),
    MapPosition(
        "Right",
        "You took the right path and lived!",
        "",
        {},
        function=exit,
    ),
])

How can we fix this? I was thinking about making everything more paramaterized. i.e. we would do this:

game_map = GameMap("someBasicStuff")

game_map.add_location("Left", "You took the left path and died", "", {}, otherData)

Any other suggestions to make it easier to use?

We should have the option for a user to add global commands, like quit.

We should have them integrated into the "fabric mesh," so a user can have one for going to a saved home, or to an inventory/other menu.

As usual, they should be able to bind to these commands.

Have them add text, license information.

I've noticed that most of the time, they are like this:

self.map_start         = self.class_data["map"].find_start()
self.map_position      = self.map_start
self.last_map_position = None
          # Lined up --^

But, sometimes they don't. When do we want them lined up?

From

You have reached a blank room.
>> eat taco
Yum.
You are now in the dining hall.

You have reached a blank room.

>> eat taco

Yum.

You are now in the dining hall.

Might also want an option for just around the prompt.

(This assumes that lower_text has been enabled)

Suppose I have a MapPosition instance with the name "My Position". If I try to assign a function to it using an event handler, and it's actual, capitalized name, it doesn't work. Here's an example.

"map_position.My Position.enter.after": func # <-- This doesn't work.

In order to get this to work, I have to type the following instead.

"map_position.my position.enter.after": func # <-- This works, but it's still a bug.

I think the best way to make this flexible is to add an event handler (like JavaScript's onLoad type thing).

To do this, we need to:

• Remove any redundant copies of variables (lazy eval, extra functions will help us maintain readability)
• Add an event handler system

To do this:

Have user pass a dictionary of string: function, where string is something like onEnterRoom and function with the MainGame is the only argument (so they can modify the game). We will need to add enough functionality that they can completely manipulate the game without borking something.

If on pages, we should disable the wiki here (to avoid confusion)

I want to add other examples

We should all accept the same licence before proceeding.

I suggest the MIT. Is that ok?

Add support for https://github.com/pwaller/pyfiglet or other programs like it.

Like I said earlier, everything that the user needs for a good game should be cactus itself.

Boolean enable

Rather than having a class_data variable, we can used forced named parameters, like this:

def add(*, a, b):
    return a + b

And force the user to type something like this:

add(a=2, b=2)

Making the coding process even cleaner and clearer.

Test on a string, as they cannot be mutated! Test on an int, also, to be sure.

Worry: Python's pass-by-object will not allow external code to edit the dictionary. I want to be sure

Go to settings and uncheck Wiki

• Liberally apply _conditional_lower() to functions
• Rename should_lower_text to case_sensitive

Just use CLASS_DATA_KEY_TYPES.keys(), instead.

I'd then rename CLASS_DATA_KEY_TYPES → CLASS_DATA_SCHEMA

Whoops. My mistake :P

Can we please establish a coding convention?

PEP 8 seems to be the prevalent style in the Python ecosystem, but we don't seem to conform with class definitions.

All established open source projects have a coding convention, so we should also.

Can we remove the prototype or is it still important?

MainGame → CactusGame
MapPosition → CactusPosition
GameMap → CactusMap

Is this okay @ShearOfDoom?

This lets rooms be dynamic -- for example, you could enter a room, knock a torch down, and the room catches on fire. If you try to enter the room again, it could deduct (for example) four health and tell you:

HOLY CRAP YOU'RE ON FIRE AAGAHGASKGHASG

Optional parameter

While the current system isn't too hard, it'd be easier for larger projects if we could use dictionary keys as references rather than indexes, like so:

{
    "choice1": "mykey",
    ...
}

and probably upload to pypi so that users can pip install it.

I could take this up and submit a pull request.