Let Em' Cook

03 February 2024

Dedicating Servers

Setting up a dedicated (or master) server using the Unreal Engine necessitates installing the source build of the engine rather than relying on binaries from the Epic Games Launcher. Therefore, the initial step was to evaluate this process to determine the feasibility of moving forward with Unreal Engine.

As with everything Unreal and most things code related, things never work out the way you want them to the very first time.

During the attempt to implement this process using the latest version, 5.3.2, compile errors unique to this version surfaced. While some of these issues were addressed with solutions found in the forum, a roadblock was encountered with others, leading to a standstill in progress.

Consequently, the next logical step involved reinstalling a different version of the engine. In doing so, all components aligned seamlessly, resulting in a successful implementation. Here are some screenshots showcasing a functional multiplayer build with a dedicated server for Epic's LyraStarterGame project.

25 February 2024

Four Arms!

Another week, another blog. This time I have finished setting up the basic Character class. I removed all the code from the WeaponComponent class from the Third Person template and put it inside the Character. For the on-screen representation, I included an arm mesh visible exclusively to the client, while the primary character mesh remains visible to other players.

This setup is also convenient as it allows for the utilization of the same animation blueprint for both meshes, without increasing animation time overhead.

The wonderful character meshes were provided by the same artist as the restaurant pack, both found on itch.io.

Theorycrafting Architecture

The next thing I did was start brainstorming the system architecture for the primary gameplay mechanics.

We are making a first-person cooking game where players cook by throwing things into each other. For example:

• A player character has the option to throw a knife at another player, inflicting damage upon impact. Alternatively, if they aim at an ingredient, such as a tomato, the knife will slice the tomato instead.

Currently, I'm conceptualizing two primary classes:

• The ThrowTarget, representing an entity targeted by a throw, such as a Character, an Ingredient, or a Utensil.
• The Throwable, encompassing objects that can be thrown, including utensils and ingredients.

When considering the structure of classes for the throwable objects, there's a choice between extending the projectile class in Unreal or opting for a more modular approach using Actor Components or an IThrowable interface.

Regarding the structure:

• Characters are distinct classes, so there's no confusion there.
• However, for utensils and ingredients, there's a bit more complexity. Utensils like pots and pans may have different states depending on interactions. For instance, throwing chopped tomatoes into a pan would alter the state of the pan. This variability doesn't apply to the knife, which remains consistent. Although both knives and other utensils can be thrown by the player, ingredients require picking up before tossing.

To address this, I'm considering structuring the classes as follows:

• IThrowable Interface: This interface can be implemented by all objects that can be thrown. It includes common functionality such as throwing and picking up from the environment. However, certain objects like knives and pans have additional attributes like cooldown times, which can be specific to them.
• IThrowTarget Interface: This interface defines behavior for objects that can be targeted by throws. Ingredients, when subjected to slashing (knife) or blunt (pan, pot) damage, may transform into something else. Utensils may also undergo changes depending on the interaction.

By utilizing interfaces, we can maintain flexibility and modularity in our design while accommodating the diverse functionalities of the throwable objects and their targets.

Sadly, that's about it for this week's update, as I've been busy with my machine learning module. Hopefully I get to dive off into the deep end soon.

10 March 2024

Source Control Shenanigans

My top priority for this week was configuring Perforce for the project. Drawing from my past experience with Perforce at Streamline Studios, I recognized its effectiveness in preventing conflicts and ensuring team members didn't inadvertently overwrite each other's work, ultimately safeguarding the project's integrity.

This turned out to not be an option in our case because we do not have the resources required to set up the necessary infrastructure for this. The next step was to start scouring the internet for alternate solutions. I tried using Git for the Revision Control pipeline within Unreal, but it does not support features such as locking assets for when someone is working on them.

After some more searching, I came across the UEGitPlugin, which appeared to be a step up from the basic Git pipeline for Revision Control. However, despite its advantages, it lacked the capability to lock assets. After discussing with my team, we concluded that for the time being, manually coordinating and communicating with each other while working on the project would suffice.

Wreaking Havok

Moving onwards, I started working on the Collision system for our Projectiles. I created an OnHit() function which I bound to the OnActorHit delegate of the Projectile.

Then I started testing and voila! Nothing happened…

After looking around a little I realised the problem was that my Projectiles were not simulating physics. Well, that was an easy fix. Right?

Turns out simulating physics while trying to make that work with the ProjectileMovementComponent is a nightmare. So, I did what any self-respecting developer would do, I started writing my own movement pipeline.

Now that sounds more impressive than it is, because I decided to simply leverage Unreal’s physics system for my needs.

A simple AddImpulseToProjectile() function later, we were finally up and running with our Collisions!

Perfect Collisions

For the interactions, I wanted to create an event-based setup for centralised collision management. Essentially, whenever a throwable collides with another, it sends the collision data to the GameMode instance. The GameMode then adds this information to a queue, which it processes in the next frame update.

The GameMode has an array of valid interactions. For example, if a knife hits a tomato we should get cut tomatoes, but nothing should happen if a knife were to hit a pot.

The UInteractionData class is a simple DataAsset that holds the pertinent data for the interactions. We simply select the two objects that interact and the resulting item, and voila, the GameMode handles the rest for us.

This is the code for the collision handling. Firstly, we make sure that we are the server. Then, we loop over the CollisionEventsQueue to make sure we have processed every interaction. The ProcessedActors is a set of AActors that keeps track of the actors whose interactions we have processed so far. This is because when object A and B collide, they both sent the collision event to be queued by the GameMode. Adding it to the set makes sure we process said interaction only once.

We then go over the interactions possible, checking each till we find the relevant interaction.

Once we have the interaction, we instantiate the ResultItem actor and add the colliding actors to the ProcessedActors set. Then, we simply iterate over the set, destroying each actor as we go. Finally, we empty the set so that it’s fresh and ready for the future.

Optimal Solutions

A much more elegant solution would be to use an object pool instead of all the instantiation and destruction. To facilitate the same, I created the following setup.

After implementing the necessary adjustments in the Character class, the game began crashing. Consequently, I decided to temporarily comment out this code to revert to a stable state, prioritizing the establishment of core systems before delving into optimization concerns.

This has also given me some time to think about the object pool architecture. It's apparent that having all these items constantly replicated across the network isn't the most bandwidth-efficient approach. A more efficient setup would involve replicating them only when required. Additionally, I'm contemplating implementing a custom pipeline to update the transform of projectiles in the future. This adjustment would accommodate lag and ensure smoother movement on client machines. Thankfully, as a result of this I have a clearer goalpost to aim for when I finally get around to start optimising the systems.

24 March 2024

Picking Up the Pace

Another week, another blog. With the Projectile system now established, it was time to proceed with implementing the item pickup functionality.

I began my implementation by adding an AActor variable and an ALetEmCookProjectile variable, both Replicated to be in-sync across the network.

Next, I devised a straightforward function responsible for assigning the CurrentlyOverlappedIngredient. This function is invoked by the Character's Tick function, which conducts a Raycast every frame to detect nearby viable actors.

This is also the part where I finally created the first interface. It is quite simple and just has two getter functions, one for the relevant GameItemData, and one for the Projectile.

Initially, the Projectile getter may appear redundant, especially within the Projectile class where it merely returns itself. However, its inclusion is strategic, anticipating future requirements in the game's Pantry area. This area will feature Containers from which Ingredients can be retrieved, and these Containers will return the appropriate Projectile. This setup streamlines the process for any class to implement this interface, facilitating easy projectile pick-up.

The PickupIngredient() function is assigned to the Pickup action. It checks to see if we already have a CurrentlyHeldIngredient and if so, drops it. Then it picks up the new ingredient.

Since we set the meta specifier 'ReplicatedUsing = OnPickedUpIngredient' for the CurrentlyHeldIngredient, it is called automatically on the Clients when we change the value of CurrentlyHeldIngredient. However, for the server we need to call it manually, which is taken care of within the PickupIngredient().

7 April 2024

To Stack a Burger

This week I realised that there was an issue with the setup of the interaction pipeline for the projectiles.

The problem has to do with the interactions regarding Ingredients that have multiple forms. Let’s look at an example for clarity: suppose we have a burger, the burger is made up of the buns, a patty, a piece of cheese and a slice of lettuce.

Employing the previous setup would necessitate creating interactions for the burger with solely the bun, then with just the patty and buns, and so forth, for each possible combination of ingredients. This was highly unfeasible and an absolute nightmare. And so, I had to figure out a way to solve this issue.

I began by adding an array of GameItemData references to the GameItemData class itself. This nested approach meant that the burger’s data would have a list of relevant data within itself.

I then had to adapt the collision pipeline accordingly, although I haven't reached that stage yet. This is because I realised the necessity of introducing a new projectile type capable of tracking the ingredients it holds and updating their representation accordingly.

However, the concept behind the collision pipeline is straightforward. Instead of instantiating the resulting item upon collision between two items, we inform the nesting item that it now contains the other item. For instance, if a burger composed solely of buns collides with a lettuce slice, the lettuce mesh on the burger projectile is activated, and the burger's internal state is updated to reflect its acquisition of the lettuce.

I was aware that the representation would vary depending on the type of item. For example, a burger may need to expand or contract based on its ingredients, while a soup would maintain its constituents' positions, merely requiring visibility adjustments.

Therefore, I devised the ModularProjectile abstract class to serve as the blueprint for all projectiles with the specified requirements.

The AdjustProjectileState() function is an abstract method that will be further developed by inheriting classes. It outlines how the Projectile should modify its mesh representation, colliders, etc., in response to added ingredients. The next logical step would involve implementing functionality to update and monitor the ingredients it contains through collisions, but for this week my update includes establishing the code for the burger's mesh and collision adjustments.

To achieve this, I introduced the ModularProjectile_Stackable class. This functionality extends beyond just the burger; it can be applied to any food item that requires stacking along a specific direction.

This code initializes the ModularProjectile_Stackable class. It retrieves all child components of the mesh, including the mesh itself, and stores them in an array called MeshChildren. The relative locations of these child components are then stored in an array called ItemRelativeLocations.

This code, part of the AdjustProjectileState() function, handles the adjustment of mesh representations, specifically the positions of child meshes. This code is to be called after the collision takes place and the internal representation of the data, alongwith the visibility of the relevant meshes, are updated.

First, the code aligns child components of the mesh based on their relative locations. Then it iterates through the child components, stacking visible components on top of each other while avoiding collision. It checks if the current child is visible and if it's not the first child. If it is visible and not the first child, it performs collision checks with the previous visible child to determine if adjustment is needed to prevent overlap. It uses line tracing to detect collisions and calculates a translation vector to move the current component to a non-colliding position above the previous visible child. Finally, it updates the world location of the current component accordingly.

The next part of the AdjustProjectileState() function handles adjusting the collider’s size to be in-sync with the size of the mesh representation.

Here's a breakdown of what each part of the code does

1. Orientation Calculation:
   • It calculates the orientation vector by subtracting the top location vector from the base location vector.
   • The resulting vector is then normalized to ensure its length is 1, representing the direction of the stack.
2. Ray Casting:
   • Two rays are cast from the base and top of the stack along the orientation vector to determine the impact points with the environment.
   • These impact points help determine the size of the collision box and the relative position of the mesh.
3. Collision Adjustment:
   • Using the impact points, it calculates the projected extent of the collision box along the orientation vector.
   • It then adjusts the box extent to fit the distance between the base and top impact points, ensuring the collision box encompasses the entire stack.
4. Mesh Positioning:
   • The relative position of the mesh is adjusted based on the projected extent to ensure proper alignment with the collision box.