Forem: Kwesikwaa Hayford

Practical approach to interface, delegate and event in Unity

Kwesikwaa Hayford — Wed, 09 Jul 2025 11:09:19 +0000

The explanation of these three key concepts has always been a bit vague to me, often using technical terms that are either confusing or impractical for truly understanding what they’re meant for.

interface
A player interacts with many objects in a game. These objects could be projectiles, lives, enemies, bullets, portals, doors etc. At any point when a player collides with the collider of these other objects, something is expected to happen. In plain language, what is expected to happen depends on which object a player interacts/collides with. However, how a developer chooses to implement it, is what we need to talk about.

if condition/switch is often the first option for handling collisions/triggers as has been demonstrated in the code below.

void OnTriggerEnter(Collider other)
{
    switch (other.gameObject.tag)
    {
        case "Enemy":
            // handle enemy trigger
            Debug.Log("enemy entered trigger");
            break;
        case "Life":
            // handle life trigger
            Debug.Log("gained a life");
            break;
        case "Bullet":
            // handle bullet trigger
            Debug.Log("got shot");
            break;
        default:
            // handle unknown trigger
            Debug.Log("unknown object entered trigger");
            break;
    }
}

This clearly does the job but the question is, is it efficient enough?, especially when several other entities are added; how many checks would have to be done in that case, is it decoupled, the questions are endless.

This is where interfaces come in handy to cleanup the situation. An interface is basically like a class but with methods and other members that are not yet implemented and the word "interface" in place of "class". The cool thing is, any class can inherit as many interfaces as they want and would then be responsible for the implementation of the methods the way its wants. For example, an interface called IBird can has Fly(), Sing(), Eat() as methods to be implemented by Eagle, Parrot and Crow classes. How these classes decide to define these methods depend on how they fly, sing or eat. "I" is mostly the first letter of the interface's name.

public interface ISomething
{
    // c# rule, it is wrong to add public here, the implementing class must add public
    void DoThis();
    void DoThat();
}

It is now the responsibility of any class that chooses to inherit this interface to define what the DoThis() and DoThat() methods should do. that is all !!! that simple !

now let's choose to do this for Enemy, Life and Bullet classes

public class Enemy: MonoBehaviour, ISomething
{
    public void DoThis()
    {
        // define what Enemy's DoThis() should do
    }
    public void DoThat()
    {
        // define what Enemy's DoThat() should do
    }
}
public class Life: MonoBehaviour, ISomething
{
    public void DoThis()
    {
        // define what Life's DoThis() should do
    }
    public void DoThat()
    {
        // define what Life's DoThat() should do
    }
}
public class Bullet: MonoBehaviour, ISomething
{
    public void DoThis()
    {
        // define what Bullet's DoThis() should do
    }
    public void DoThat()
    {
        // define what Bullet's DoThat() should do
    }
}

Each class handles responses its own way decoupled from the player.
The OnTriggerEnter function now looks much cleaner and scalable:

void OnTriggerEnter(Collider other)
{
    ISomething entity = other.GetComponent<ISomething>();
    entity?.DoThis(); // take notice the null-conditional operator(?) :)
}

The code is simpler, decoupled and easy to maintain. Also note that interface names typically describe what they do. For example IInteractable, IKillable, or IDamageable. With this, I believe you can now revisit the topic with a different perspective. Good luck!

delegate and event
There is a GameManager or SoundManager that runs an action or actions when something happens, for example when a player dies. Delegates and events are ideal for this. They allow classes to subscribe to events without being tightly coupled.
A delegate defines a method signature (what a method returns and what parameters it takes), and can reference or point to any method that matches this signature. Event acting as a broadcaster, notifiers those methods that have subscribed to the delegates to take action when an action happens in the order they were added. In practical terms, five methods somewhere are called when a player dies.

public class Player
{
  public delegate void PlayerDied();
  public static event PlayerDied OnPlayerDied;

  // this is static because it is accessing a static event; c# rules :)
  public static void PlayerDiesHere()
  {
      OnPlayerDied?.Invoke();
  }  
}

// subscribers, GameManager and SoundManager
public class GameManager : MonoBehaviour
{
    void OnEnable()
    {
        // the FunctionForPlayerDied() has the same signature as the PlayerDied delegate
        Player.OnPlayerDied += FunctionForPlayerDied;
    }
    void FunctionForPlayerDied()
    {
        // whatever must be done here
    }
    void OnDisable()
    {
        // it is important to unsubscribe
        Player.OnPlayerDied -= FunctionForPlayerDied;
    }

}
public class SoundManager : MonoBehaviour
{
    void OnEnable()
    {
        Player.OnPlayerDied += SoundForPlayerDied;
    }
    void SoundForPlayerDied()
    {
        // do as you please :)
    }
    void OnDisable()
    {
        // never forget to unsubscribe :)
    }
}

It is important to unsubscribe in either OnDisable() or OnDestroy to avoid unexpected behaviour.

In the example above, i defined delegate separately from the event. While that is fine, there is a simpler approach using the built-in Action type.

This:

public class Player
{
  public delegate void PlayerDied();
  public static event PlayerDied OnPlayerDied;

can be replaced with:

public class Player
{
  public static event Action OnPlayerDIed;

  // and if the function should have parameters, you write it this way
  public static event Action<string> OnPlayerDIed; //one parameter
  public static event Action<string, int> OnPlayerDIed; //two parameters
  // ie Action<T1,T2> in that order

I hope this gives a practical perspective to these three concepts.
Have fun building cool stuff! cheers!!

Make Unity's Grid Layout Group Dynamic/Responsive

Kwesikwaa Hayford — Sun, 27 Apr 2025 08:23:30 +0000

I recently worked on a task that involved displaying a list of users with their specific user details in a one column grid. While it is a one column grid, each row is based on a prefab that inherently has 4 columns for specific details.

The unexpected challenge was that the Grid Layout Group grid cellsize does not scale with parent by default and therefore a change in the aspect ratio or screen size pushed the grid outside the bounds of the parent panel, maintaining its initial size and pushing information out of frame. The grid cellsize X is fixed and does not change.
No amount of anchor point tweaks worked. I switched to the vertical layout group component hoping that would save the day. That did some good but something the grid layout group gives was missing. Perhaps I do not know how to properly use both components. yh maybe!

The script below, together with these three important steps helped me to achieve a super responsive grid layout that scaled the cellsize with the parent grid.

Per my setup, the reference resolution is 1920 x 1080 on the canvas scalar.
Size and anchor points of the parent object/panel properly set.
The script attached to the object with the grid layout group component.

using UnityEngine;
using UnityEngine.UI;

[ExecuteAlways] //for editor
[RequireComponent(typeof(GridLayoutGroup))]
public class DynamicGridSize : MonoBehaviour
{
    // onrecttransfrom works in both editor and production. 
    // gets triggered when there is a change in parent panel size or screen size
    [Tooltip("cellsize Y at the reference height")]
    public float referenceCellHeight = 108f; // set the right cellsizeY at the reference resolution
    [Tooltip("canvas height, should match the root canvas's scaler reference resolution Y")]
    public float referenceHeight = 1080f; // set to 1080 cos the project is 1920x1080
    public bool fixedHeight = false; // totally optional but different gridlist needed fixed height so this was necessary in my case

    private GridLayoutGroup grid;
    private RectTransform rectTransform;

    private void Start()
    {
        grid = GetComponent<GridLayoutGroup>();
        rectTransform = GetComponent<RectTransform>();
        UpdateCellSize();
    }
    // onrecttransfrom works in both editor and production. 
    // gets triggered when there is a change in parent panel size or screen size
    private void OnRectTransformDimensionsChange() => UpdateCellSize();

#if UNITY_EDITOR
    // OnValidate works only in editor. triggered when values in inspector changes
    //  hence good for visualization
    private void OnValidate() => UpdateCellSize();
#endif

    private void UpdateCellSize()
    {
        if (grid == null || rectTransform == null) return;

        float scaleFactor = rectTransform.rect.height / referenceHeight;
        // rectTransform.rect.width, makes the cellsize x dynamic
        // referenceCellHeight * scaleFactor, makes the cellsize y dynamic
        grid.cellSize = new Vector2(
            rectTransform.rect.width,
            fixedHeight ? cellHeightAt1080 : cellHeightAt1080 * scaleFactor
        );
    }
}

I hope someone finds this useful.
Cheers !!

Houdini: Setup Fractured Glass The Right Way For Seamless Rendering

Kwesikwaa Hayford — Fri, 22 Dec 2023 09:39:19 +0000

You have a fractured window glass pane, or a glass ball for RBD simulation and rendering, but the inside faces of the fractured pieces show in the render even before the fractured simulation plays. The demo below shows the problem on the left and the fix on the right

The obvious solution is to resort to "tricks" to hide the pieces but Houdini since 18 introduced nodes to handle that problem; two nodes actually.

Let's go!

A basic geometry fractured with the glass preset of the "RBD MaterialFracture" node. = The first important step is to drop an "RBD ConnectedFaces" node
The next step is to do whatever you wish to do with the fractured object. ie. the sim or animation or whatever it is you want to do.

The last step is to drop an "RBD Disconnected Faces" node and choosing Delete Connected Mode

That is it !! Simple! huh? What happens is that, all the inside faces of the "unsimmed" faces are deleted while the simed faces are not. This creates a hollow geometry of a sort and only fills the areas that get disturbed. In the wireframe below, the first box is a clipped version of the fracture box. It is clear that the box is hollow at that point until any area gets hits and has to fall apart (last image).

Have fun!

React js: Avoid Needless Rebuilds

Kwesikwaa Hayford — Fri, 22 Dec 2023 05:29:16 +0000

useState is the react ecosystem's way of rebuilding or reactivity but this triggers a rebuild of the entire UI. In Vue, reactivity is limited to variables and the component that parents them.

Using useState in some cases is very important, but in some other cases it may be detrimental and must be used strategically.

There are ways to mitigate this problem but these are my two personal favourites. One route is to build separate components for things that change and allow the useState to happen locally, only in those component without affecting the entire UI and the second is to resort to the signals package for reactivity.

Building separate components
React Native example:
You are building a chat app and therefore has to make sure that the Text Input has onChangedText property assigned to a function which has a useState to allow binding. This is simple but it also means on every key that is entered in the textbox, the entire interface rebuilds. To avoid this, simply build the Text Input and the the send button as a separate component. That component is then imported and used in the rest of the app. This means the useState happens only in that component while the parent component only receives the values from the child's props without rebuilding the parent component.

export default function InputText({send}){
    const [text,setText] = useState('')
    console.log("child rebuilding as proof...")
    return (
        <View>
            <TextInput value= {text} placeholder='Enter Prompt' placeholderTextColor="white" multiline onChangeText={setText}/>
            <TouchableOpacity onPress={()=>{if(text)send(text);setText('')}}>
                <Text> send</Text>
            </TouchableOpacity>

        </View>
    )
}

export default function Parent(){
    const send = (val){
        console.log(`value is ${val}`)
    }
    console.log('parent rebuilding for proof....)
    return(
        <View>
            <InputText send={send} />
        </View>
    )
}

In the above example, you will realize that "parent rebuilding for proof" is logged only once while "child rebuilding for proof..." gets to be logged whenever a key is punched. Clean and simple. rebuilding only happens in that small component.

Using React Signals
React Example:
This code demonstrate how a pop up modal results in a rebuild of both the parent and modal components whenever the modal is toggled.

import { useState } from 'react'

export function PopUp({prop,emit}){
    console.log('Rendering Popup......')
    return (
        <>
            {prop && <div style={{position:"relative"}}>
                <p>This is the popup</p>
                <p>
                    And this is the proped data {prop}
                </p>
                <button style={{background:"red", color:"white"}}
                    onClick={()=>emit(false)}
                >
                    close
                </button>
            </div> }
        </>
    )
}

export default function Parent(){
    console.log('Rendering parent...')
    const [dataToPopUp, setPropData] = useState(false)
    return(
        <>
         <button onClick={()=>setPropData(true)}
         >
             Show PopUp
         </button>
         <PopUp prop={dataToPopUp} emit={(val)=>setPropData(val)}/>
        </>
    )
}

Below is a signals approach. It utilises a global signals variable which can be accessed from any component

import {signal} from '@preact/signals-react'

const dataToPopUp = signal(null)

export function PopUp(){
    console.log('Rendering Popup......')
    return (
        <>

            {dataToPopUp.value && <div style={{position:"relative"}}>
                <p>This is the popup</p>
                <p>
                    And this is the proped data {dataToPopUp.value}
                </p>
                <button style={{background:"red", color:"white"}}
                    onClick={()=>dataToPopUp.value = null}
                >
                    close
                </button>
            </div> }
        </>
    )
}

export default function Parent(){
    console.log('Rendering parent...')
    return(
        <>
         <button onClick={()=>dataToPopUp.value = 'hello'}
         >
             Show PopUp SIGNALS
         </button>
         <PopUp/>
        </>
    )
}

Both approaches rebuilds only the child component. Efficient and Done !

Houdini: Varying carve node values for multiple splines

Kwesikwaa Hayford — Fri, 22 Dec 2023 04:32:39 +0000

While Houdini allows splines/lines to grow through the carve node, it gets tricky when a bunch of splines need to be grown over time at varying speed.

This code might help you if you are in such a position.

fit01(rand(detail("../meta","iteration",0))*ch("slider")*2,ch("slider"),1)

Let's get right into it!

Drop a grid, size x= 2, y =10
Adjust rows or columns based on your preference, in this case i want to extract the columns so I pushed it to 50.
Mind you, I am only using a grid for the demo, what you decide to use is up to you.
Drop a polypatch node for the extraction. choose columns in the connectivity property and tick "Output polygons".

Drop a "foreach primitive" node. In the "foreach_begin" node click on "Create Meta Import Node". Rename the meta node of the foreach begin set of nodes to something shorter(optional but since it will be needed in the code, making it shorter is better. I made it "meta" in this case)

Now drop the carve node and pipe it between the "foreach_begin" node and the "foreach_end"
This is where the magic begins. in the carve properties, click on the parameter edit menu icon and choose edit parameter interface

Drag a float parameter and add it to the existing parameters list, in my case it, I placed it under the "Second V" parameter. Now rename the "name" and "label" properties; i named both "slider", ticked the range option and changed its values from 0-10 to 0 -1. click apply and accept.

Back in the carve parameter panel, depending on what you want to slide over, be it "First U" or "Second U", paste the code into it.

fit01(rand(detail("../meta","iteration",0))*ch("slider")*2,ch("slider"),1)

Now slide your "slider" float parameter you added and there you have it. Animate the slider.

The code in detail

Important part: detail("../meta","iteration",0) : as you can see the "meta" node is referenced here. What the detail does is, it gets the value of each polygon or iteration: the default being 0
The ch("slider") is the custom slider which multiplies with the detail value.
detail("../meta","iteration",0))*ch("slider")
Note that these alone will work, but will create an undesirable ramp across the splines and that is where the rand function comes in
rand(detail("../meta","iteration",0)) * ch("slider"). this uses the detail iteration value as a seed to create random values between 0 to 1. This will make the effect work nicely with the desired randomisation.
The only issue this presents is, some will get to the destination point and others wont. To counter this the fit01 function is used. It takes the randomised value, and uses the slider as min and 1 as max.
fit01(rand(detail("../meta","iteration",0))*ch("slider"),ch("slider"),1)
This works perfectly, speed is varied and they all get to the end point when the slider gets to 1.

This should be enough but in order to have some sort of speed control I added a multiplier of 2 to the slider value
fit01(rand(detail("../meta","iteration",0))*ch("slider")*2,ch("slider"),1) Totally optional.

So there you have it. have fun.

Houdini: Keep A Chaotic Character Vellum Cloth Under Control

Kwesikwaa Hayford — Thu, 21 Dec 2023 17:18:25 +0000

Does the cloth on your animated character look chaotic and out of your control?

Vellum has a "one toggle switch and a slider" solution for this problem. The slider allows you to control how chaotic/tamed the cloth can get. Let's get started!

Below is my setup. I basically used a cube as the main character in this case and transformed it with a trig function to make it oscillate on the y axis. A point velocity node ends the cube's node chain. Getting the character's velocity is very important for the setup and needed for the fix to work. The cloth is a grid with an initial vellum cloth setup to get an already draped cloth for as initial state. Simple network

First, the cloth is attached to the cube via a Vellum Constraint Attach To Geometry node. A primitive group I made on the cube and named "att" is fed into the group slot of the constraint. The point velocity node from the cube is piped into the collision geometry input of the constraint node. A vellum solver is then dropped to demo how it goes. Attached but definitely chaotic. This is where the solution comes in.

A second Attach to Geo Constraint is added after the first one(mind you we are keeping both). This time all the group slot will be left empty and the stretch stiffness set to 0. The Velocity Blend property under the Stretch tab is then activated. The amount is now based on what feedback you get and what you are going after. In my case I settled with 0.3. Keep in mind that without the point velocity node from the cube, this will not work.

That is it. The hip file is in a github repo Houdini-Vellum-Blend-HipFile