AGF/Knit Transition to Knight
Last updated
Was this helpful?
Last updated
Was this helpful?
As Roblox developers, you may have been using frameworks like AeroGameFramework (AGF) or Knit to structure your projects. Both of these frameworks follow a modular approach, offering client-server communication patterns, service organization, and utilities that ease game development. Now, if you're transitioning to the Knight framework, this article will guide you through key differences, similarities, and how to adjust your workflow to fit the Knight framework’s approach.
The Knight framework offers a flexible, modular, and scalable structure tailored for Roblox development. It emphasizes strong typing, configuration through enums and types, and integrates easily with modern tools. Here are some reasons you might consider transitioning:
Enhanced modularity with well-defined service and object separation.
Configurable behaviors using KNIGHT_CONFIG
, KNIGHT_ENUM
, and KNIGHT_TYPES
.
Improved organization of shared, client, and server scripts across the game's services.
Before jumping into code, let’s go over some key concepts in the Knight framework:
Services: Just like in AGF or Knit, Knight uses Services to structure server-side and shared logic. Services are stored under ReplicatedStorage/Knight/Services
for shared services and ServerScriptService/Knight/Services
for server-only services.
Objects: These are reusable components, typically representing specific game logic that can be instantiated multiple times. Knight encourages storing these under ReplicatedStorage/Knight/Objects
.
Configurations and Types: Knight makes heavy use of configuration files like KNIGHT_CONFIG.lua
and KNIGHT_TYPES.lua
, which define custom behaviors, types, and constants to be reused across the codebase.
Packages: Knight uses a Packages
folder structure that contains utilities or third-party packages. This setup is similar to how AGF or Knit organizes third-party dependencies.
Let’s break down the transition by focusing on core areas like service management, client-server communication, and initialization logic.
In AGF/Knit, services are organized in ServerScriptService
or ReplicatedStorage
(for shared services). Similarly, Knight organizes services across these locations, but with a focus on stronger separation between server-only and shared services.
AGF/Knit Example:
Knight Example:
In Knight, services are also module-based and are organized under Knight/Services
. Here's a transition example of how you would define a service in Knight:
In AGF/Knit, client-server communication is handled via RemoteFunction
abstractions like Client
tables within services. Knight, on the other hand, exposes remote functions dynamically through the Knight.Remotes
API.
AGF/Knit Example:
Knight Example:
In Knight, you would dynamically expose server functions to the client using the Exposed-Server Functions API. Here’s how you would achieve the same functionality:
Both AGF and Knit have initialization flows, but in Knight, you have more configuration options using the KNIGHT_CONFIG.lua
and KNIGHT_TYPES.lua
files to specify game-wide settings and behaviors.
AGF/Knit Example:
Knight Example:
As you transition to Knight, it’s important to understand its directory structure and how services, objects, and configurations are separated:
Server-only services: src/ServerScriptService/Knight/Services
Shared services: src/ReplicatedStorage/Knight/Services
Objects (reusable game logic): src/ReplicatedStorage/Knight/Objects
Configuration files: src/ReplicatedStorage/KNIGHT_CONFIG.lua
, KNIGHT_ENUM.lua
, KNIGHT_TYPES.lua
This clear separation of concerns allows for easier management of client-server logic and reusable components. We highly recommend going to Welcometo read further about our framework!