Implement Ticket Sprite

[jilliebean]

Closes:#97 With this commit, I have implemented a ticket sprite. When the chef moves to the ticket window and off screen ticket sprites renders in the chef's hand. I fixed the the offset so food and ticket renders in his left and right hand.

[brforest]

I really like this pull request, I just have one issue with one of the changes in order_window.py. @jilliebean if you could take a look at my comment that would be great, thanks! Other than that, I think it is good to merge with master.

[brforest]

I just ran this branch, it looks really good!

[Neunis]

Looks good. One point of discussion I would like to make regarding this implementation: the chef retrieves a ticket (and the ticket displays very nicely), the chef carries the ticket to the hasher (wonderful) and a countertop value is assigned to the ticket (so far so good), I know you put in work to have the chef hold the food in one hand and the ticket in the other. Therefore, would it not be more intuitive to have the ticket disappear (much like if one had visited a diner or any other restaurant) and only have the respective food sprite be displayed upon completion of the order at the window? The functionality of hashing is a key is given (in our case a ticket), the hashing tells where in the index array the key can be found (our countertops), so both would not need to be present upon delivery of the order. It may be perceived as odd due to our theme of a Diner which we are using as our base connection.

[mfraser4]

@neunis interesting perspective. I thought of it like the ticket indicates which table the food goes to in a real diner, but for hashing, the index isn’t required to be returned, and the education should be our main focus. However, another point would be both are necessary to complete (and validate) and order, meaning we can’t just kill it. I don’t have a final answer, just presenting what I see as well. Any other thoughts, team?

[brforest]

I definitely see where you are coming from @Neunis. However, we can't just kill it (as @mfraser4 pointed out), and to me it makes intuitive sense to return the matching ticket with the food. Although we only have one ticket available at a time for our game, in a real kitchen there will be multiple tickets active at once and many orders that need to be completed. Often, the ticket will be left near the order to clarify which order the food belongs to. So I think it is best to leave it the way it is in this branch.

[dvasavda]

I see where you are coming from as well @Neunis , it would seem more intuitive to make the ticket disappear after the food is taken. However; as @brforest says, it may not be too intuitive to make those changes as that sprite can't be killed. But you made a great point @Neunis , makes more logical sense. For the sake of the project, I'd leave the branch as is. @jilliebean this was a really good implementation on your part, the game makes more sense now, especially since the ticket is no longer imagined. It clears up a lot of confusion I had in the game! Good job. I'm down to merge the pull request.

[Neunis]

Awesome. I see the logic and appreciate the implementation and discussion. Well done, Jill. Have at it @dvasavda