TheEggNoodlet

Date: 27 June 2020

Customer spawning

With our deadline looming ever closer, I’ve started scrutinizing which of our features are truly essential. Initially, we were going to have two types of customers — customers ordering takeaway and dine-in customers. 

Take away customers would come into the restaurant randomly and place orders for single dishes of chicken rice directly at the cashier. Dine-in customers would come in groups of 2 to 4, need to be seated at an appropriate table, have their orders taken and served to them, then their tables cleaned.

Dine-in customers would introduce waves of orders for the chef. Takeaway customers were supposed to add extra difficulty by introducing a constant stream of new orders the chef had to tackle alongside the waves.

If we balance the difficulty of cooking and the spawn rates of customers, however, I believe that we can make do without takeaway customers.

Developing a Spawn System

I’ve never really had to develop a proper spawn system before — all the game objects I had to spawn had an equal probability of spawning, so I just used Random.Range to randomly spawn a game object from an array of objects. I didn’t have to tweak the probabilities of different types of spawns before. 

I had to spawn different sizes of groups of customers to dine-in, so this lack of experience hampered me slightly. This video helped me get started, however. I truly am grateful for the bountiful resources and tutorials available on the internet. 

With most of the tables being two-seaters and up, I decided to spawn more couples. That way, players would frequently have to grapple with the choice of seating a couple at a 4-seater if they’re out of two-seaters, or leave the 4-seater open for potential groups of 3 and 4.

Balancing the Overall Gameplay Difficulty

The aim of our game is for the group of players to sustain the restaurant for as many days as they can in one playthrough. Each day, the players will have to deal with more customers with less patience. 

Kind of like an endless level with waves of challenges (think Plants Vs Zombies Endless Survival Mode), except between each wave, the gameplay will be paused and your performance evaluated. 

If we were to hard code specific values each day should have (e.g. the max number of customers to spawn each day, the frequency of customer spawning and the rate of decrease of customers’ patience levels), we’d have a finite number of levels for players to hussle through. 

As such, we need to find a general pattern we’d like the difficulty to rise in, then run the base values set for level 1 through a formula based on the pattern we want to use.

I played around with Desmos, an online graphing calculator to determine what formula would suit the difficulty curve we were picturing.

This first one helped capture the general curve, but the change in difficulty was a little drastic.

While playing Overcooked, we observed that the first few levels were relatively easy to perform well in. The difficulty scaled slowly, such that only at the 6th level did we start struggling to get high enough scores to get a 3/3 star ranking. As such, we decided that the gradient of our difficulty should be such that around the 6th day, the difficulty of the game would be twice as hard as that of the first day.

This second curve had the kind of gradient we were looking for. As you can see, however, the changes in the graph are quite small — the difficulty of the game would increase from 0.2 units on day 1 to 0.4 units on day 6. In the grand scheme of things, that’s not a lot of difference.

This brings me to the curve we arrived at. Of course, what we’ve proposed is merely theoretical in nature. Our difficulty curves are not set in stone and should change after playtesting is done.

Patience system

The simplest feature I’ve implemented so far. I created a method that would reduce the fill amount of an image of a circle as the patience of the customer runs out. The customer will start out with a patience level based on whatever float was passed into the method as an argument.

When I’ve implemented an evaluation system, a method that penalises the player’s customer service evaluation score should be called when the timer runs out, while a method that improves their score will be called if the customer is served before they have lost 10% of their patience.

What’s next?

Customer behaviour!

Making the customers walk into and queue in the restaurant.

Creating a depth-based alpha shader so that customers will fade in and out as they walk through the entrance of the restaurant.

Allowing the player to bring customers to tables.

Have the customers sit down and generate orders.

Date: 26 June 2020

A note before I begin: This devlog is quite different from my usual style of devlogs. Not everything I’m talking about is directly related to the development of Yi’s Eatery, so I understand if you’re not particularly interested. With that aside...

Where I’ve been

Hihi! Sorry I’ve been MIA for a while.

I was in charge of creating content for a social media assignment for two weeks, so all my energy went into that for a while. I developed a chicken-themed Snake game and crafted a tutorial series you can follow to produce the same game as me. You can check out the tutorial series here!

It was exhausting to do. Half my time went into taking and editing screenshots of the development process. Making easy-to-understand and high-quality content is really tough. I had a lot of respect for educational content creators like Brackeys, VR with Andrew, and Cyan before, but my experience has caused my admiration for their efforts to skyrocket.

So many pictures...

Style of Devlogs

I went on a bit of a tangent there. Putting all that aside, I’ve decided to take a different approach to my devlogs.

I like to keep as quiet about my struggles as possible during development because I do not want to be looked down upon and seen as incompetent. I recognise, however, that it is through being open about one’s struggles and sharing one’s progress honestly that humans can lean on one another and grow together. As such, I’m going to use my devlogs as a chance to reflect on all that I’ve learnt each step of my development journey.

On top of that, my teachers are using our Jira board and devlogs to monitor our progress on this assignment. I personally hop around a bunch and make small bits of progress everywhere, so it often looks like I haven’t made much progress during each sprint because I can’t mark any issues as complete on the Jira board. I’m still discovering my working style and how to best make use of the scrum methodology, so I’m sure I’ll eventually figure out how to keep going. Progress on Yi’s Eatery

I’ve finally gotten my hands on the VR headset, so I can finally jump fully into VR development! ... Or so I thought. I’m having a harder time figuring out how I should go about testing my builds on the headset than I anticipated. My computer has always had strange issues with connecting to android devices. That’s exacerbated my confusion regarding setting up the Oculus Quest.

I got so frustrated just trying to figure out how to set up the device that I gave up and went back to working on the mobile version of our game. I’m aiming to return to VR development next week. 

In the meantime, I’ve been working on customer-related mechanics and other miscellaneous mobile mechanics.

Finished on: 21 May 2020 Last semester, I worked on a Mixed Reality cooking simulator for the Microsoft Hololens.

To show that the pancake in the pan was being cooked, I had the material of the pancake change from the raw to cooked texture over time. I achieved this by using a shader that blended two albedo maps together. The more time the pancake spent in the pan, the more the material of the pancake showed the cooked texture and less of the raw texture.

What was done:

This feature was honestly pretty easy to implement. I created one method to blend the raw texture with the cooked texture, and another texture to blend the cooked texture with a burnt texture. The pan itself identifies whether the food has met the conditions required to burn (not putting oil in the pan first / cooking the pancake for too long), then calls the respective methods.

Possible improvements:

As mentioned in my devlog about the chopping mechanic, I felt that the heating mechanic was a little too lackluster to provide the frantic energy we were aiming to provide.

I am considering changing this mechanic such that players need to shake the pan in which the object sits vigorously for the ingredients to cook.

I will soon be collecting the VR headset from my teammate so that I can work on the VR mechanics more easily. I hope setting it up won’t be too rough :x

Final result:

Finished: 20 May 2020 (Wow! That’s a lot of 20s)

Next up on my list was something I’ve been both excited and hesitant to try - chopping food up!

What was done:

Using this API, I made it such that, when a knife comes in contact with a pancake, the pancake’s mesh would split at the point of contact.

Challenges and their solutions:

As I was mostly testing the mechanic out within Unity, I did not realise until much later that my chopping mechanic had a couple of VR-related issues.

The method with which I am splitting the object into two works like this:

When the collider of an object with the knife script comes into contact with a choppable object, the original choppable object is deleted, and replaced with two meshes the size of the two halves on the opposite sides of the knife. These two meshes do not have a collider component on them.

As this caused the slices to fall through the counter and floor of the scene, I added a collider to each half spawned. This, however, introduced a new issue.

In order to make an object grab-able in VR devices, the object must have the ‘XR Grab Interactable’ component, while the player’s hands must have a ‘XR Direct Interactor’ component. On top of that, both the player’s hands and the object must have a collider. 

I wanted the player to be able to pick up the pieces of the object they had cut. As such, I attempted to add the ‘XR Grab Interactable’ component to each of the pieces spawned. 

However, the XR plug-in comes with something that constantly checks all objects with the aforementioned component. If a new object with the interactable script suddenly appeared out of the blue, the grab interactable checker would scream in protest. 

My teammate is revamping the chopping mechanic to better suit the limitations of the XR plug-in.

Possible improvements:

We want the player to be able to suspend their disbelief sufficiently and truly believe that they are cooking in a kitchen. However, we want the cooking experience to still be fun. We want the cooking experience to bring the same frantic energy that games like Overcooked give their players. As such, we are considering dropping the realism of the chopping mechanic a notch and making the chopping process more abstract.

Final result:

Finished: 19 May 2020

Finally, I’ve finished a VR mechanic! 

As the lead VR developer, I was to code the core VR mechanics. I, unfortunately, did not have access to the headset, so developing the mechanics was pretty tough. I could only test whether the mechanics worked in the Unity Editor, and would have to cart the mostly-working build over to my teammate with the headset — @theboynoodlet — to test. 

In our game, the VR player was to be the chef of the restaurant. They would cook and assemble dishes to fulfill the orders flooding in. The first mechanic I decided to work on was pouring. Essentially, when a tap was turned on or a bottle tilted far enough, I wanted something that was able to contain liquids to slowly fill up with a liquid, and for particle effects to pour out of the source of the liquid (the tap or bottle of liquid). 

For the very first iteration of my prototype, I was planning on using pancakes as a placeholder food item. Pancakes were used for two reasons:

I had some pancake textures from my previous project that would be quick and easy to import in.

Pancakes are wide and flat — any changes in their texture would be obvious, making double-checking that my code (for changing the texture of the pancake over time) would be easier. This will make more sense when I explain the development of the heating mechanic.

What was done:

Following this tutorial by VR with Andrew, I created a bottle that would pour oil when tilted far enough. 

When the particles pouring out of the bottle hit something that can contain liquid, such as a pot or pan, liquid will start filling up the container.

Possible improvements:

In the final game, the player will not have to pour liquids from a bottle. The player will merely have to put their container under a tap for a couple of seconds for the pot to fill.

If possible, I would like to make the liquid in the container slosh around. I will likely either follow this tutorial by VR with Andrew or use this shader / shader graph by Minions Art 

The final result:

Finished: 7 May 2020

Designing good UI is tough. You have to balance the visual appeal and functionality in the layout of all the UI elements. As our UI/UX designer was having a tough time with the wireframes, I designed some sample layouts for her to work off of.

Some of the screens I laid out were:

Title screen

Menu

Lobby

Error screens

As our game is a multiplayer game, we need players to connect to the same network and join a specific game room. The lobby serves as the area for the players to wait for their friends to join the room after they have joined successfully.

Our game is set in a Hainanese chicken rice stall in 1980s Singapore. As such, I thought it would be fitting if our menu layout was reminiscent of Chinese restaurants’ menus — boxy and straightforward. Pictured below is one of my references.

Fatty Ox HK KItchen | Image credit: Gregory Leow | Taken from here

This is how the title screen (left) and menu (right) turned out:

The title screen was to be an illustration by @thecatnoodlet​, so that was left blank. As joining a game room was going to be the key action we wanted players to take, I made it the biggest button in the menu screen, and aligned it to the right so that it would be in the comfortable reach of the players’ hands, as determined by this source.

After hitting ‘Join room’, the device searches for games being hosted on the network the device is connected to. If a room has been found, it has to present the option of joining the identified room to the player. If no room was found or the device is not connected to wi-fi, the appropriate error message should be displayed. These are the layouts I designed for these situations:

To ensure that all the buttons are easy for the player to hit, I aligned them to the bottom right corner once more. 

Once the players successfully join a room. they will be taken to a lobby to await the arrival of other players. I came up with two layouts for this lobby, one inspired by the layout of the lobby from Pummel Party (right), and another inspired by the character select screen of the Toca Kitchen mobile game (left).

The references: 

The sample layouts:

After passing my wireframes to @thecatnoodlet​, she started to refine them and produce samples of the UI elements.

TL;DR

What was done:

Research

Old Chinese menu layouts

UI of similar screens in other games

Layout of mobile UI screens

Challenges:

Determining what would be representative of the 80s

Balancing interesting and unique visual design with recognisable UI patterns.

Other notes:

What was done Finished: 4 May 2020

Creating a new project in Unity greets you with this screen:

Side note: My team and I had agreed beforehand to all use version 2019.3.4f. It was the latest version of Unity when we first started working on this project.

For most of our course, our teachers had us stick to using the standard 3D render pipeline. We had been developing simple applications and games for computers and mobile platforms, so we never had too many issues. 

However, this time, we’re developing for the Oculus Quest. VR headsets — especially stand-alone headsets — can’t handle as much real-time rendering as computers can. As such, we were considering using the Universal Project Template (UPT), a pipeline that aimed to optimise graphics. 

On top of that, Unity had just introduced new extended reality (XR) development methods. They had released the XR Plug-in that would allow you to develop for multiple XR platforms at once. Our team could either use this new XR plug-in or use Oculus’ Oculus Integration plug-in from the Unity Asset Store.

To ensure that our team’s Unity workspace was properly prepared for development for the Oculus Quest, I decided to test out the different plug-ins and render pipelines available to see what would best suit our needs.

What was done:

Compared the advantages and drawbacks of using the standard 3D pipeline versus the Universal Project Template (UPT. Previously known as the LWRP).

Set-up 3 projects to be tested out on the Oculus Quest:

XR plug-in in 3D standard pipeline

XR plug-in in UPT

Oculus Integration Plug-in in UPT

Following this tutorial by Valem, I created and built a simple bowling scene in each project with the XR plug-in. In the project with the Oculus Integration, I followed this tutorial (also by Valem) and created a barebones scene with nothing but a cube and a plane.

I’ve only used the LWRP twice before. I have very little experience with it. Even though the Unity Documentation clearly lists down the differences in features supported by the UPT, I still did not fully understand the significance of any of those differences.

Testing out the differences with the different pipelines and plugins was difficult as I did not have access to the Oculus Quest, what with the quarantine and all. I had to send the builds to my teammate and wait for him to get back to me.

If I were completely honest, our team couldn’t tell much of a difference between the pipelines. As such, our team decided that we would build our prototype in the 3D standard pipeline first because of our familiarity with the pipeline and its quirks. Eventually, we plan to import our prototype into the UPT. Also, we chose to stick with the XR plug-in because of the ease it added to VR development, as compared to the Oculus Integration plug-in.

What was done well:

I believe I organised my files well! It may seem small, but following naming conventions really helped me to find the things I needed easier.

Possible improvements:

Finished: 11 May 2020

For the past few weeks, I’ve been taking an online course on programming with C# on Code Academy. It’s been very informative! Some of my key takeaways include:

Clearer grasp of how to use classes as objects.

How to implement constructors.

The significance of labelling variables as private or public.

A more solid understanding of the use cases of switch cases as opposed to if else statements.

Finished: 23 April 2020 

What was done

Game design diagrams

Action, Gameplay, Emotions (AGE)

Game Structure

Metrics

Overview of game and rules 

Challenges faced and their solutions 

It was difficult to pinpoint what the key player actions and gameplay were while creating the Gameplay Loop. Referencing articles and forums helped give me some examples of gameplay actions I could focus the loop on, though!

What was done well

By writing all our design decisions down, I was able to spot areas of concern our group needed to iron out. For example, I realised that we had not decided on how the customers would behave upon finishing their meals.

Possible improvements

Looking up the methods in which people implement movement and throwing mechanics in their games might have helped me to create more accurate metrics.

I’d like to streamline the diagram-creation process better in the future. Perhaps I could make a blank template for the diagrams, since they often use similar formats.

Other notes

Unity Tutorial #1: Run with Dust~

Add satisfying flair to your game’s movement by having little dust clouds puff out of your players as they run! 

Step 0: Observe how other games’ particle effects work.

Think about what is common or what is different across several games to determine what kind of artistic liberties you can take with your particle effects + what kind of behaviour your particle effects should have. 

Observations

Animal Crossing New Horizons

Dust cloud sprites are realistic

Dust cloud starts small and increases in size.

Dust is spreading and dissipating.

Dust clouds appear close to feet of player character.

Dust clouds fade in quickly then out slowly.

Overcooked 2

Dust cloud sprites are cartoonish and round.

Dust cloud start big and decrease in size.

Dust clouds appear behind the player character.

Dust clouds appear suddenly, then dissipate into smaller clouds.

Step 1: Draw some cartoonish clouds!

3 of around the same size will do. Arrange them in the same file, equidistant to one another. This is your cloud sprite sheet.

Step 2: Open Unity and create a material.

We’re using the Standard 3D pipeline for this tutorial.

Right-click the Assets window and navigate to Create > Material. Change the material’s shader to Particles/Standard Unlit. Change the rendering mode to ‘Fade and the Color Mode to ‘Multiply’.

Import the cloud spritesheet made in step 1 into Unity and set it as the material’s albedo.

Step 3: Create a particle system. Assign the material to it.

Right-click the Hierarchy window and navigate to Create > Effects > Particle System. Drag and drop the material from step 2 onto the particle system in the Hierarchy window.

Step 4: Check all the relevant particle effect properties.

Select the particle system in the Hierarchy window and view its properties in the Inspector window. Check all the properties shown below.

Step 5: Adjust the numbers as depicted.

Step 6: Attach the particle system to your character! 

Put it slightly behind the character’s feet. The character we are using here is Mix And Jam’s mascot!

Hi! I’m Krystal, the visual effects + sound effects designer, and the programmer of Noodlets Studio! I’ll be using this blog to post progress reports on the development of our upcoming game, Yi’s Eatery! Occasionally, I will post some Unity tutorials, too!

A little bit about myself:

Talk to me about extended reality (XR) stuff! i.e. Anything related to virtual reality (VR), augmented reality (AR), or mixed reality (MR).

I’m a jack-of-all-trades, master of none ;(

There was a point in my life where I really loved scrambled eggs. I’d eat it everyday in between meals as a snack; Hence the blog name.