MAIN_GAME = MainGame(
"Test Game",
"Welcome to the simple test game.",
"> ",
"Uh-oh! Wrong input!",
GAME_MAP,
True,
)

> 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

> Oh I see.

Do you also want to do logging and/or user input?

The use for these functions would be for validation purposes mostly

> Suggestion:

1. We throw an exception that could be caught by the gamemaker
2. We create a log file somewhere with a timestamp, error message, and the list of previous command used (to replicate error)
3. We alert the user that the game reached an error **by the developer** and what they should give the dev when reporting this

Optional: we require an email to show to the user when an error occurs.

I don't like alerting the user for a catchable exception (it seems pointless to have an

> Add support for https://github.com/pwaller/pyfiglet

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

> I just thought of this right now and thought that this would be a good thing to add sometime in the future.

I'm trying to add stuff for people to do if they want to join the project (so we don't shrug our shoulders and waste help)

> `MainGame` → `CactusGame`
`MapPosition` → `CactusPosition`
`GameMap` → `CactusMap`

Is this okay @ShearOfDoom?

> 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

> 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

> But that doesn't solve the issue.

I could externally edit the dictionary and it would be unvalidated

> Ok, but we still can't edit any of the other items.

So we need to prefix it with an underscore no matter what.

Do we want specific stuff like set name and get name? Or a generic set_attribute("key", value) function?

> 1. An idea: we could validate this every time `_handle_event()` is called.
2. I still don't think that we should be storing this stuff internally in a dictionary (from readability and validation purposes)... why do you what to do this in the first place? What advantage does this offer?

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


```python
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?

Merge pull request #48 from Annonomus-Penguin/6-8-15-lower-everything

Closes ShearOfDoom/Cactus#30

Merge pull request #49 from Annonomus-Penguin/6-8-15-lower-everything

Fixes ShearOfDoom/Cactus#44

> Just in the middle of some functions. Like this:

while True:
cactus_position_data = self.class_data["map"].class_data["data"][self.cactus_position]
choices = cactus_position_data.class_data["choices"]

> Always?

What if it's like this?:

```python
something = "hi"
doSomething()
another = "haha"
```

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

```python
import cactus.game
import cactus.map
import cactus.position

my_game = cactus.Game(data)
```

Then, we could also do stuff like this later:

```python
import cactus.color

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

> Cactus has to be lowercase according to PEP 8.

This is convention:

```python
import sys
```

> Okay, how about this.

* Rename `CactusSource` to `Cactus`, or `cactus`.
* Keep the same name for the file `game_map`.
* Keep the same name for the file `map_position`.

> You're right about `cactus.position.Position()`. I just tested it.

Okay:

- Rename to `cactus`
- I don't want `cactus.cactus_position.CactusPosition()`
- I don't want `cactus.cactus_map.CactusMap()`

> So, in short, we should do this.

* Rename `CactusSource` to `cactus`.
* Rename the file `cactus_position` to `position`.
* Rename the file `cactus_map` to `game_map`.
* Rename the file `cactus_game` to `game`.

> How about this?:

- Rename to `cactus` (lower C)
- Rename to `cactus.flowchart.Flowchart()` (I don't want to have to do `cactus_map`, so I think we should start calling it a flowchart, as that's what it really is)
- Rename to `cactus.position.Position()`
- Rename to `cactus.game.Game()`
- Set the `__init__.py` file to this:

```python
from game import Game
from flowchart import Flowchart
from position import Position
```

Now the user could do this:

Renamed everything (COMMIT BROKEN DO NOT USE)

Made so I can see what changes I made in the renamed files

Merge pull request #51 from Annonomus-Penguin/6-9-15-break-all-the-things

Closes ShearOfDoom/Cactus#50; Closes ShearOfDoom/Cactus#47