Abstract:

This video initiates a mini-series on software architecture for real-time applications and games, emphasizing simplicity and modularity. The core architectural principle introduced is the separation of a "core" library containing reusable systems (application, windowing, event handling, main loop, renderer utilities) from the "application" layer which houses custom, application-specific logic. The presenter demonstrates how custom behavior is introduced through "layers," which are dynamically pushed onto an application-managed stack. The implementation uses OpenGL (chosen by community poll), CMake for project structure, and GLFW for cross-platform window management and context creation. A minimal flame-rendering application serves as a practical example. The discussion highlights the benefits of this design in promoting clean code, scalability, and ease of development by abstracting backend details from domain-specific functionality.

Software Architecture for Real-Time Applications and Games

• 0:00 Introduction to Architecture Mini-Series: The video begins a new mini-series on software architecture for real-time applications and games, focusing on simplicity and avoiding unnecessary complexity, inspired by observed code review issues.
• 0:35 Technology Choice & Independence: OpenGL was chosen for the series based on a community poll, but the presenter stresses that the architectural concepts are universally applicable across different technologies.
• 1:06 Core vs. Application Separation: The fundamental architecture separates core reusable systems (e.g., application, windowing, layers, event system, main loop, renderer utilities) into a static library, while application-specific user code resides in a separate executable module.
• 2:47 Modular Core Design: The core library itself can be further modularized into multiple dynamic libraries if specific functionalities are not universally required across all applications.
• 5:01 Project Structure Example: A GitHub repository demonstrates the file structure with app and core directories, managed by CMake (though build system details are deferred to a potential future video).
• 5:53 Clean main Function: The main function in the application module is kept minimal, serving solely as an entry point to launch the application with a specified configuration and push custom "layers."
• 6:25 Live Demo: Simple OpenGL Application: A basic application is shown, rendering a flame using an OpenGL fragment shader from Shader Toy.
• 6:50 Application Specification and Layers: An ApplicationSpecification struct defines initial parameters (e.g., window settings). Custom functionality is injected into the application via "Layers," which are pushed onto an internal stack.
• 8:04 Layer Interface: The Layer class acts as an interface (with optional empty implementations) allowing custom behavior via OnEvent, OnUpdate, and OnRender methods, defining what happens on events, frame updates, and rendering.
• 9:51 Key Takeaway: Clean & Organized Code: The core benefit emphasized is separating complex backend logic (main loop, event system) from application-specific code, providing a "sandbox" for developers to focus on unique application features in a clean, organized environment.
• 11:13 Application Class & Main Loop Structure: The Application class (designed as a singleton for global access) initializes GLFW (a cross-platform library for windowing, OpenGL context, and events) and creates a Window instance. The Application::Run method contains the main loop.
• 12:49 Main Loop Operation: The main loop continuously polls events, checks for application termination, calculates delta time, and then iterates through all active layers, calling their OnUpdate and OnRender methods before swapping buffers (Window::Update).
• 13:53 Reasons for Update/Render Separation: The OnUpdate and OnRender calls are separated to allow for potential multi-threading (e.g., a render thread), ensure data consistency across layers before rendering, and facilitate profiling.
• 15:17 Layer Management: Layers are managed within the application using a std::vector of std::unique_ptr, ensuring single ownership.
• 15:43 Future Topics: Upcoming videos will delve deeper into the layer system (including state machines for transitions between layers) and the event system.