GUIDE TITLE: Advanced Code Architecture for Core, Part 4: Descendent’s Framework Architecture
ESTIMATED COMPLETION TIME: 10 minutes
CORE VERSION: Any
SUGGESTED PREREQUISITES: Intermediate-level coding
TUTORIAL SUMMARY:
Part 4 of a series of articles on designing a better code architecture that solves the problems with the way code is typically structured in Core.
EXPECT TO LEARN:
- What Descendent's Framework Architecture is
- Why Descendent's Framework Architecture is beneficial to code in Core
- How Descendent's Framework Architecture can be implemented in Core
END PRODUCT VISUALS:
- (Imagine beautiful code here.)
TUTORIAL:
Part 3 examined Inversion of Control as the pivotal architectural concept that enables other creators to integrate or customize a System, without modifying the System's code. With Inversion of Control, designated stub functions in a System are overridden by override scripts, to inject code for implementing integrations and customizations. This innovation solves the inherent problems that otherwise hinder adoption of project frameworks and Community Content packages on the Core platform.
Alongside MVC and ECS architectures, Inversion of Control provides the final piece of the design for a better architecture for Core games. Whereas the conventional way of structuring code in Core suffers from tightly-coupled dependencies, and game logic being entangled with the Hierarchy structure of game objects, the architectural concepts explored in this series of articles provide the means of avoiding those flaws. Hence, the final step in our quest is to bring together all of these concepts into a comprehensive code architecture for Core games.
Descendent's Framework Architecture
Descendent's Framework Architecture is an architectural pattern conceived for Core games. Based upon the principles of MVC and ECS architectures, and Inversion of Control, it's designed to fulfill the needs of a User-Generated Content (UGC) platform, where code often needs to integrate with frameworks and code from other, decentralized creators.
Under Descendent's Framework Architecture, code is organized into Services—modular "micro-frameworks" distributed as Community Content packages, and meant to be assembled together to implement the features of a game. These Services can be tailored for each game by using Adapters, which inject code for integrating with other frameworks and code; and Handlers, which inject game-specific game logic. Like Services, any Adapters and Handlers can also be distributed as Community Content packages.
By facilitating distribution of Services, and Adapters and Handlers, as modular Community Content packages, Descendent's Framework Architecture promotes the growth of a code ecosystem. Code for integrating or customizing frameworks can be shared with other creators (or reused among a creator's own games) as easily as the frameworks themselves. And all of it can be kept updated to the latest versions by simply right-clicking on their package in Project Content, then choosing "Download Latest".
Once learned, Descendent's Framework Architecture provides a powerful pattern for creators to structure their code after, and an intuitive pattern for other creators (including non-coders) to work with, that greatly enhances the experience of creating games on the Core platform.
Service
- Is an ECS System
- Is a collection of cohesive scripts, which implements a feature
- Script asset in Project Content that contains Service-specific game state for relevant game objects, and the Service's core game logic
- Script in Client Context and/or Server Context that serves as a centralized entry point for the Service by receiving events, or running a repeating
Task - Other supporting scripts as-needed
Adapter
- Is an Inversion of Control override script
- Script in Client Context and/or Server Context that injects code for integrating the Service with another Service or other code
- Can be distributed as a Community Content package (by leaving custom properties that reference Services or other dependencies empty, to be filled in later by other creators)
Handler
- Is an Inversion of Control override script
- Script in Client Context and/or Server Context that injects code for customizing the Service with game-specific game logic for a Group
- Can be distributed as a Community Content package (by leaving custom properties that reference Services or other dependencies empty, to be filled in later by other creators)
Catalog
- Script in Client Context and/or Server Context that registers templates, game objects, or ID's with a Group, and associates each entry with static game data
Binding
- Is a cross between a Handler and a Catalog
- Script in Client Context and/or Server Context that registers templates, game objects, or ID's with a Group, and associates each entry with a function containing game-specific game logic
Configuration
- Empty script in Static Context, with custom properties for specifying Service-wide configuration settings
Start
- Is a checklist script
- Script in Client Context and/or Server Context that tracks the loading of the Service's Adapters, Handlers, Catalogs, Bindings, and other relevant script objects in the Hierarchy
- Applies configuration settings from Configuration script to the Service
What's Next
See "Descendent's Community Content" for a collection of the author's Community Content packages that implement Descendent's Framework Architecture.