November 14, 2017, by Stuart Moran

Corrupt Kitchen VR Dev-Diary 2

The Digital Research Team are working with Computer Science, Law and Politics on developing a VR game about corruption.

Dr Paul Tennent describes the on going development below:

Welcome to the next section of the Corrupt Kitchen VR development diary. Today we’re going to talk a bit more about realising the game experience. First though we’ll discuss style, then talk about the practicalities of delivering the gameplay.

Finding a style

To make the newly named Paradise Café work as an engaging world some decisions had to be made about its visual style. We wanted to be familiar and with a humorous twist particularly as the work is addressing some quite uncomfortable subjects. One early decision was about what kind of café it would be. What kind of food would we serve. To keep the task-complexity down, we elected to go with burgers. Just plain old burgers. With that in mind we decided to give the kitchen a 50s diner feel, but one that could be aging – thus the plaster on the walls is cracked, the tiles are old-looking the fluorescent lights flicker, but the surfaces and appliances are clean (at least at the start). We wanted it to feel like a space that looked correct both when clean, and when filthy, so it was built with layers of dirt that could be blended in over time. We wanted it to feel ‘lived in’.

As for the cast of characters, we needed three: workers, customers and an inspector. For the customers, we decided for both economy of production, and in reference to the fact the café serves only burgers, to make these a never ending queue of Elvises. This is perhaps my favourite graphical aspect of the project. For the workers things were a little trickier. We would have to allow both illegal and genuine workers. So as to avoid pushing any inappropriate buttons, we elected to make the workers characters be robots. This would also allow us to use text-to-speech for their voices, removing the need to record large amounts of dialogue. Following the same theme, we have also made the health inspector’s avatar be a robot, being distinct from the worker in colour (blue for the workers, red for the health inspector). The characters and most of their animations come from the excellent free library of pre-rigged characters and animations available from www.mixamo.com, with some additional animations sourced from Carnegie Mellon University’s incredible motion capture database (http://mocap.cs.cmu.edu).

Core game concepts

For the concept of Corrupt Kitchen VR to work as a game, it was necessary to create some core rules. We had to consider resources and outcomes. At a basic level this is a game of making as many burgers as you can in a set amount of time. Thus time is your primary resource, and money (your score) earned from selling those burgers is the outcome. However, a major aspect of many games is the capacity for choice. This experience is supposed to be about corruption – will you as a player choose to comply with various corruption/health and safety guidelines? – if you don’t you’ll earn more money, but at what moral cost?

The basic idea this is this: you have a task to do – make burgers – this uses your primary resource: time, and is the only way to make money. All additional tasks which do not make money, but are necessary for compliance should also eat that time resource – not so much that you can’t make money, but enough that you would make more if you ignore them. This is true of health and safety compliance, but we also wanted to include additional corrupt activities that would more simply make you more money. Thus we have the option to accept cash only (often a suggestion that VAT is not being paid), and to hire illegal workers (again suggesting a lack of tax/minimum wage being paid). These choices mark the player as more corrupt but without costing them a time resource.

Playing in a corrupt way is a choice, but also carries a risk. The game includes a health inspector. At the end of the game, the kitchen is inspected and the player is fined for their various violations. Of course a canny player can address many of the things an inspector would see before they arrive… An even more corrupt player might also be tempted to bribe the inspector to look the other way about their violations.

To make a burger

To keep the experience to a sensible length, the game is limited to ten minutes. We had to create a system of burger making that balances complexity with simplicity – and is more complex the more compliant the player is with the health and safety regulations. We decided on the following core steps for making a burger as a good balance.

Notice in the minimal steps, though the first burger requires the additional two steps of getting the meat out of the fridge and placing it in the grinder, further burgers require only five steps to complete, compared with the nine steps from making a burger in a health and safety compliant way.

So how do we make this actually happen? The environment is made up of a number of static and interactable objects. Each interactable object can be either used or grabbed. Lets go through the steps of making a compliant burger and address each one at a time.

  • Get meat from fridge. The fridge is a usable interactive object. It tests each frame if a controller is colliding with it (i.e. within its bounding box) and if the trigger button is pressed. If so its use conditions are met and it creates a new meat This new object is also an interactable object, this time with the grab mechanic. It listens checks each frame if a controller is colliding with is and if the grab button is pressed it attaches itself to the controller – now moving wherever the controller moves. Each time the player handles raw meat, the game logic marks their hands as dirty.
  • Place meat in grinder. In initial testing of the game, we created a physic playground. All the interactable objects would behave in sensible ways – i.e. a dropped object would fall on the floor etc. While this makes for a fun sandbox environment, it creates a less linear task logic. Since this is a quite fast experience, at just ten minutes, to simplify the task, objects have a location object, so dropping a grabbed object – releasing the grab button – will cause an it to fly to its next location. This means that when the player releases the grab button the meat will fly to the grinder. While a little counter-intuitive, this does support non-expert players.
  • Grind meat into burger. The grinder is an interactable object with the use It detects the collision of the controller and the trigger button being pulled, and whether there is meat in the hopper and a free plate for the burger. If this is the case, it spawns a new burger and plops it onto the plate next to it.
  • Return meat to fridge. The meat after being placed in the grinder is given a new location (the fridge). Thus grabbing it and releasing it will cause the meat to fly back to the fridge. At this point, the game logic is informed that the meat is no longer spoiling.
  • Wash hands. The taps are an interactable object with the use They detect the presence of a controller and the trigger button. When activated, they animate a flow of water using a simple particle system, and notify the game logic that the player has washed their hands.
  • Place burger in pan. The burger has the grab Once grabbed its drop target is set to the nearest pan on the hob that does not currently contain a burger. If no such pan is available, the plate becomes the drop target. Once the burger is in the pan, the grinder is notified that it may spawn another burger if activated.
  • Wait for burger to cook. The burger cooks as longs as the bob is switched on, the pan is on the hob and the burger is on the pan. The texture on the burger has its main colour changed over time from a meaty pink to a burgery brown. If left too long it will go fully black. After fifteen seconds of cooking, the burger is considered cooked and a steam particle effect is generated. After thirty seconds a smoke effect is applied, and the burger is considered over-cooked. After forty-five seconds a fire effect is applied – the burger should be fully blackened at this point. The Elvises do not react kindly to under/over/blackened burgers.
  • Transfer burger to roll. Nobody would touch a hot burger in a pan, not even a virtual one, so this time, instead of grabbing the burger, the player should grab the pan, which also has the grab They should then hold the pan over the pre-prepared roll and tip it upside down. The effect is achieved by having two invisible objects attached to the pan – one above and one below. If the upper object is detected below the lower one, this tells us the user has turned the pan more than 90 degrees, and the burger moves to its new target (on top of the roll).
  • Hand burger to customer. The plate object has the grab As long as there is a burger on the roll it can be grabbed as per the other grabbable objects. Its new target is the hand of the waiting Elvis. As soon as the player lets go of the plate, the game logic triggers a reset of the various aspects. The queue of Elvises moves on to present another hungry king of rock and roll, the kitchen worker prepares a new plate with a roll, and the payment for the burger is added to the cash register. Depending on whether the player has set the register (which is a usable object) to accept cash only, the player receives the payment including or excluding the sales tax.

 

Additionally, other tasks occur which eat into your precious time:

Each of these events can be ignored if the player so chooses, or addressed at the cost of time. For example as time passes, the floor becomes increasingly dirty. A quick once over with the mop will fix that. If the floor gets too dirty an infestation of mice will occur.

In the next instalment of the dev-diary, we’ll look at these extra events, and then at how the safety inspector works.

 

Next blog in series: When Law and Computer Science Collide: How an interdisciplinary project is letting me do more than I could on my own

Previous blog: Developing the Corrupt Kitchen VR

Stuart Moran, Digital Research Specialist for Social Sciences

Posted in Data VisualisationDigital Initiatives