Add Dynamic Recipes

[nathan-miller23]

Update the OvercookedState and OvercookedGridworld classes to include recipe lists that can change with time. This would involve adding timestep dependencies to all_orders and bonus_orders

[bmielnicki]

Do we want to have "all_orders" and "bonus_orders" OvercookedState/OvercookedGridworld variables in its current form? Does any external code reference them directly?

I see 2 ways to deal with them:

1. Along with "all_orders" and "bonus_orders" variables add "temporary_orders" variable for orders that expire with time and/or are time-dependent in any other way. All temporary_orders will work in an object-oriented way with Order class.
2. I can just put all orders into the "orders" class variable using Order class. If order receives a bonus reward or not would depend purely on its internal variables, not on the OvercookedState variable it belongs to. Code would maintain backward compatibility in terms of creating a layout from ".layout" files - being in the "start_bonus_orders" field would just grant a bigger reward variable value.

[nathan-miller23]

I actually think the most general (and backwards compatible) way to do this is to make start_all_orders and start_bonus_orders nested lists. This was the original intention that never got fully developed.

For example, a user might specify in the .layout file start_bonus_orders=[[ { "ingredients" : ['onion', 'onion']}, {"ingredients" : ['onion'] }], [{"ingredients" : ['tomato']}]]. This would correspond to two separate bonus order lists. So the initial bonus orders are a 2onion soup and a 1 onion soup, then, you could "advance" the bonus orders (probably want to do this in step_environment_effects) upon completion of a bonus order to the next list, which would be a 1 tomato soup.

This way, you can fully specify an arbitrary list at every advancement, and it's backwards compatible because providing a flat list behaves the same way it currently does (static, no order advancements)

[nathan-miller23]

this is definitely not the only way to do it, but I would try and steer you away from adding an additional temporary_orders list, as this makes the already cumbersome game logic even more complex for the user (having just the "all_orders" and "bonus_orders" lists is already confusing to users, so I would be opposed to adding an additional list) and would also require GUI updates in overcooked-demo

I would also advise against modifying the Recipe class here. I intended it to be a lightweight, Object Oriented container for organizing ingredients into recipes, and it implements some fairly complex caching inside the constructor. Again, none of these are hard rules, I just think you'll have a much easier development experience if you add the extra logic to the Gridworld class and leave the Recipe class as logic-free as possible

[bmielnicki]

I'm not planning to edit the Recipe class here. My plan is to put a Recipe object as a necessary part of the Order object.

If "all_orders" and "bonus_orders" are confusing and additional list is not a viable option I will try to unify "all_orders" and "bonus_orders" into one in the backward compatible and intuitive way. If there is a need for full backward compatibility (that includes support for referencing variables like "bonus_orders" directly) it can be reached by adding property methods that by reading "orders" variable can generate a "bonus orders" list.