DOCSEARCHbyAlgolia
Submit Docs

StonyBear Programming Development Sharing

website·Indexed 29 days ago

https://www.stonybear.com

A collection of resources and guides on game development and algorithms. Key topics include Unity best practices, the GJK (Gilbert–Johnson–Keerthi) algorithm for convex shape collision detection, and improving code quality using design patterns and SOLID principles.

Tokens
65K
Snippets
137
Records
340
Agent score
48%

What's inside StonyBear

  1. Overview of SOLID Principles for Software Design

    SOLID is a mnemonic for five core principles of object-oriented design intended to make software more understandable, flexible, and maintainable:

    1. Single Responsibility Principle (SRP): A class should have only one reason to change.
    2. Open/Closed Principle (OCP): Software entities should be open for extension, but closed for modification.
    3. Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of its subclasses without breaking the application.
    4. Interface Segregation Principle (ISP): No client should be forced to depend on methods it does not use.
    5. Dependency Inversion Principle (DIP): Depend on abstractions, not concretions.

  2. Overview of SOLID Principles in Unity

    SOLID is a mnemonic acronym representing five core principles of object-oriented design intended to make software more understandable, flexible, and maintainable. In Unity development, these principles help prevent the creation of 'monolithic' classes that are difficult to maintain and extend. The five principles are:

    1. Single Responsibility Principle (SRP)
    2. Open/Closed Principle (OCP)
    3. Liskov Substitution Principle (LSP)
    4. Interface Segregation Principle (ISP)
    5. Dependency Inversion Principle (DIP)

  3. Overview of UI Toolkit for Unity

    UI Toolkit is a high-performance, reusable UI system based on web technologies (HTML/CSS concepts). It is the recommended system for modern UI development, though it may not support every feature found in the legacy Unity UI (uGUI) system.

    For learning, Unity provides the User Interface Design and Implementation ebook and the UI Toolkit Sample -- Dragon Crashers project on the Asset Store to demonstrate runtime UI implementation in Unity 2021 LTS and newer.

  4. Overview of the GJK (Gilbert–Johnson–Keerthi) Algorithm

    The GJK (Gilbert–Johnson–Keerthi) algorithm is used for collision detection and calculating the distance between convex shapes in 2D or 3D space. It is widely implemented in physics engines such as Box2D and Bullet. Unlike traditional methods that test every edge or vertex for intersection, GJK determines if two shapes intersect by checking if the origin lies within their Minkowski Difference. Instead of constructing the full difference set, GJK uses support mappings to sample the boundary and iteratively approximates the origin using a simplex.

  5. Overview of the GJK Algorithm for Convex Collision Detection

    The GJK (Gilbert–Johnson–Keerthi) algorithm determines if two convex shapes intersect by checking if the origin (0,0) lies within their Minkowski Difference. Instead of explicitly constructing the full Minkowski Difference set, GJK iteratively samples the boundary using support functions to build a simplex (the simplest possible polytope for a given dimension) that attempts to enclose the origin. GJK only works for convex shapes; concave shapes must first undergo convex decomposition.

  6. Overview of SOLID Principles for Object-Oriented Design

    SOLID is a mnemonic for five core principles of software design intended to make object-oriented code more understandable, flexible, and maintainable. These principles serve as the foundation for many design patterns:

    • Single Responsibility Principle (SRP): A class should have one, and only one, reason to change.
    • Open/Closed Principle (OCP): Software entities should be open for extension, but closed for modification.
    • Liskov Substitution Principle (LSP)
    • Interface Segregation Principle (ISP)
    • Dependency Inversion Principle (DIP)

  7. Overview of the GJK (Gilbert–Johnson–Keerthi) Algorithm

    The GJK algorithm is used to calculate the distance and detect collisions between convex shapes in 2D or 3D space. It is widely implemented in physics engines such as Box2D and Bullet, as well as in robotics and computer graphics. Unlike traditional methods that test individual edges or vertices for intersection, GJK determines if two shapes intersect by checking if the origin lies within their Minkowski Difference. Instead of constructing the full difference set, GJK uses support mappings to sample the boundary and iteratively approximates the origin using a simplex.

  8. Overview of the GJK Algorithm for Convex Collision Detection

    The GJK (Gilbert–Johnson–Keerthi) algorithm determines if two convex shapes intersect by checking if the origin (0,0) is contained within their Minkowski Difference. Instead of explicitly constructing the full difference set, GJK iteratively builds a 'simplex' (the simplest possible shape for a given dimension) using support mappings to approximate the origin.

    Key constraints:

    • GJK only works for convex shapes.
    • For concave meshes, a 'Convex Decomposition' must be performed first to break the mesh into convex pieces, which are then processed individually via GJK.

  9. Overview of the GJK (Gilbert–Johnson–Keerthi) Algorithm

    The GJK (Gilbert–Johnson–Keerthi) algorithm is used to calculate the distance between convex shapes and perform collision detection in 2D or 3D space. It is widely utilized in computer graphics, robotics, and physics engines such as Box2D and Bullet. Unlike traditional methods that test every edge or vertex for intersection, GJK determines if two shapes intersect by checking if the origin lies within their Minkowski Difference. Instead of constructing the full difference set, GJK uses support mappings to sample the boundary and iteratively approximates the origin using a simplex.

  10. Apply the Single Responsibility Principle (SRP) in Unity

    The Single Responsibility Principle (SRP) states that a class should have only one reason to change, meaning it should focus on a single piece of functionality. In Unity, this is mirrored by the component-based architecture (e.g., MeshFilter, Rigidbody). Instead of creating a 'monolithic' script that handles input, movement, and audio, you should split these into smaller, modular components. This improves readability, scalability, and reusability. A common rule of thumb is to consider refactoring when a class exceeds 200-300 lines of code.
    // Refactored approach: Player acts as a coordinator, while logic is split
[RequireComponent(typeof(PlayerAudio), typeof(PlayerInput), typeof(PlayerMovement))]
public class Player : MonoBehaviour
{
    [SerializeField] private PlayerAudio playerAudio;
    [SerializeField] private PlayerInput playerInput; 
    [SerializeField] private PlayerMovement playerMovement;

    private void Start()
    {
        playerAudio = GetComponent<PlayerAudio>();
        playerInput = GetComponent<PlayerInput>(); 
        playerMovement = GetComponent<PlayerMovement>();
    }
}

public class PlayerAudio : MonoBehaviour { /* Audio logic only */ }
public class PlayerInput : MonoBehaviour { /* Input logic only */ }
public class PlayerMovement : MonoBehaviour { /* Movement logic only */ }

  11. Apply core software engineering principles for clean C# code

    To maintain a scalable and maintainable Unity codebase, developers should adhere to these fundamental principles:

    • KISS (Keep It Simple, Stupid): Seek the simplest solution to a problem. Avoid over-engineering or reinventing wheels when Unity's built-in APIs (e.g., Hexagonal Tilemaps) already provide the necessary functionality.
    • YAGNI (You Ain't Gonna Need It): Implement only the features required for the current task. Do not build speculative functionality for future needs that may never materialize.
    • Root Cause Analysis: Avoid 'coding around' a problem with quick fixes (e.g., using the null-coalescing ?? operator to silence a NullReferenceException without investigating why the null occurred). Investigate the underlying cause rather than applying a band-aid.
    • Continuous Improvement: Treat code cleaning as a daily habit rather than a one-time event. Balance the need for new features with regular refactoring, but avoid 'refactoring for the sake of refactoring'—only refactor when it provides a tangible benefit to the team or the project.

  12. Compare numerical integration methods for physics engines and animation

    In physics engines and animation (e.g., springs, rigid bodies, cloth, and AI movement), differential equations are used to advance the state of a system over discrete time steps (Δt). Given a first-order equation $\dot{y} = f(t, y)$ or a second-order equation $\ddot{x} = a(x, v)$, the following four common numerical integration methods are used to approximate the next state:

    1. Forward Euler: A simple first-order method.
    2. Backward Euler: An implicit method often used for stability.
    3. Runge-Kutta 4th Order (RK4): A higher-order method providing significantly better accuracy.
    4. Verlet Integration: Commonly used in molecular dynamics and cloth simulation due to its stability and symplectic nature.