Shared Worlds: Recursive Cooking Structures

Before I properly intro this particular project concept, I want to bat around some of the subsystems of the game, since it's a bit of an agglomeration. The first system in question is the cooking interface, mainly because it was the most recent system that caught my attention and received a little more fleshing out as a result.

I've always enjoyed life-sim games, ever since the original Harvest Moon on the SNES. Something I've wanted to explore in these types of games is a more robust cooking system, where the player can improvise and even devise his own dishes. Yes, this sounds kind of lame but I'm a sucker for granular crafting systems and the player expressions that can be found within.

The Structure

The path I'm thinking of taking is a recursive, lisp-style structure to a recipe. Working from the top down, the recipe is defined as processes that have parameters that can be the output of other processes. A rough example in some kind of syntactical language might look something like this:

Chili:
simmer[30 minutes,low](mix(brown(ground beef),chop[fine](onion[1/2 medium]),chop[coarse](bell pepper[1 whole],black beans[1 can, not drained],diced tomatoes[2 cans, not drained],tomato sauce[2 cans],))

Chili Spice Mix:
mix(cumin[1 T],sage[1 T],garlic powder[2 t],black pepper[1/2 t],cayenne pepper[1/2 t],cinnamon[1 pinch])

This will probably be more of an XML hierarchy structure in the final version, but this was the first way it popped into my head. Chili, in this case, is the result of 'simmering' several ingredients, including one that is a process, 'browning' with an ingredient 'ground beef'. Another ingredient is 'chili spice mix', which is another recipe of a sort that involves mixing several other ingredients.

The nesting allows for as much depth as I want, and the player can potentially get pretty creative with dishes.

Verbs & Tools

Processes in the above recipe would be executed with different in-game objects the player would need access to. Mixing would require a bowl of some sort, simmering would require a skillet and stove-top. The actual interface for this is still up in the air, but simply having the items in a kitchen should be adequate for now. I'm not interested in doing some sort of mini-game for each step of the recipe at this point.

So each tool has a list of verbs it can enact. The skillet can saute, simmer, fry, brown, etc. Each ingredient has a list of verbs that work on it. Meat can be browned, fried, boiled, broiled, etc. Each step in a recipe then has verbs that are required for that node to be completed, as shown above.

Tool Quality, Ingredient flavor, Character skill

I'm not of the camp that thinks every facet of a game should impact the overarching systems in some significant way. Sometimes expression and choice just for the sake of it is ok. (The extreme case of this for me was Spore, which I think took choice irrelevance a little too far) Having said that, I plan for the choices available in this cooking system to impact and have an effect on the larger systems in the game.

Feeding into this system will be systemic properties of the entities involved, namely the player caharacter, the ingredients and the tools he is using. A lot of these will be raw numbers (e.g. tool quality, the character's cooking skill) that can tally up pretty directly to a quality rating, maybe involving some dice rolling behind the scenes. Something I'd also like to employ is a flavor harmony system (discoverable by the player in some fashion) where complementary ingredients will enhance a dish. FoodPairing is a good example of something I'd like to shoot for.

Higher quality means a 'better' consumable for the player. I'm thinking of swiping the stomach meter from Contact (food based items take up space in the stomach when used, and slowly digest, making room for more) and making higher quality foods give better benefit for less real estate in the stomach. (food slots and 'density' colors, stat effects for duration of occupancy in stomach, 'hungry' status effect)

The Hierarchy

To allow for ingredient abstraction (e.g. A recipe simply calling for 'vegetables') I plan on implementing a class system for ingredients. This will tie into the world entities the player will be collecting for use in cooking, and will have a pretty standard object oriented tree structure. There will be higher level distinctions like 'meat', 'fuit', 'vegetable', and within those classes will be progressively finer distinctions, based on how much detail I want to put into the world and the things that can be harvested from it.

This also allows for recipes to call for more arbitrary ingredients. An omelet could optionally include X number of 'vegetables'. A kabob could involve grilled 'meat' and grilled 'vegetables'.

In the next post on this system, I'll go into:

• Scaling & Automation
  Making recipes serve an arbitrary number of people. Finding ways to make the process for the player simpler (choosing 'make chili') after the first time the recipe has been completed. Meshing with other systems so the player can make devices that assemble food from recipes.
• Accessibility & Interface
  It's of utmost importance to me that this system is accessible to players. I want to expose all the working parts that the player needs to see to form a model of the system, hide all the unnecessary bits behind the scenes and provide a smooth interface to manipulate the system as easily as possible.
• Shortcomings
  Explore the shortcomings of the system, ways it could be improved, etc.