Project Sunrise brings together several gameplay-facing systems in one blueprint-only project: interaction, dialogue, quests, actor collection, actor registration, save handling, and UI stack management. An example map is included to show these systems in action and give a clear view of how they are set up.
That blueprint-only structure is a practical part of where the project fits in production. Setup configurations stay visible, which makes it easier to inspect how things are wired and adjust base classes when necessary. At the same time, the project is set up with scalability in mind, so the usual path is to create child classes and override core functions rather than rebuilding the foundation.
Project Sunrise as a blueprint-only gameplay foundation
This is not a single isolated feature pack. It reads more like a starting framework for projects that need multiple connected gameplay systems working together early on. Instead of treating interaction, conversation, and progression as separate problems, Project Sunrise places them side by side inside the same blueprint environment.
That matters in a real workflow because initial gameplay setup often turns into repetitive groundwork: establishing how actors talk to each other, how players trigger events, how dialogue branches are selected, how quests advance, and how UI layers are managed during testing. Project Sunrise is aimed directly at that stage. The included example map supports that use by showing the systems operating in context rather than leaving them as abstract components.
Interaction System, Signal Emitters & Receivers
The interaction system is highly configurable and can manage different interaction inputs on a single actor. That makes it suitable for scenes where one object needs to respond in more than one way instead of being locked to a single prompt or action path.
Movement support is part of the system as well. Characters can move to interactables or to specific locations referred to as Move to Marker. Interaction montages can also be played, which gives interactions a more directed presentation when an action needs animation support. An interaction camera system is included too, providing camera movement that complements the interaction itself.
That same camera system carries over into dialogue, which helps the package feel connected rather than split into unrelated modules. In practice, that means interaction flow and conversation flow can share a visual language instead of requiring separate camera handling logic for each feature.
Signal emitters and receivers extend this setup into broader actor-to-actor communication. With those components, interactions and world events can be linked quickly. A receiver can handle multiple emitters and trigger different events as needed, which simplifies cases where one actor needs to react to several world states or several triggers. In production terms, this can reduce the amount of custom glue logic needed just to make unrelated actors respond to one another.
Dialogue System and Quest System
The dialogue system supports complex dialogue trees created entirely in blueprints. It includes audio playback, montage support, and use of the interaction camera system to shape conversations. Rather than treating dialogue as a basic text exchange, the system is structured to handle a more staged presentation with camera and playback elements folded in.
Conversations are built through Dialogue Modules, and those modules can be changed at runtime. There is also a dialogue selection module that handles the logic used to decide which dialogue module should be used. Relevant dialogue data for each module can be saved by the system as well. Together, those parts point to a setup where dialogue is not just authored once and played back the same way every time, but selected and managed according to game logic.
The example dialogue audio uses text-to-speech for demonstration purposes. That keeps the focus on how the system behaves rather than on bespoke recorded performances.
The quest system follows a similarly modular approach. Quests are defined from a base Quest Object, where the initial Quest Task is established first. As tasks are completed, they determine which subsequent tasks are added next. This creates a chain of progression directly from task completion rather than requiring each step to be assembled as a disconnected event.
Task Listeners are attached to tasks and can be swapped easily to change the completion conditions. From a workflow standpoint, that is one of the clearer production-oriented details in the project. It suggests a quest structure where progression logic can be revised without needing to rebuild the task itself every time a completion rule changes.
Actor Collection System, Actor Manager, and Generic States Save Component
Project Sunrise also includes support systems that help hold larger gameplay structures together. The actor collection system is used for registering and retrieving key actors inside collections. Those collections can be populated in the editor through an editor utility widget, without adding extra components to the actors involved.
Actors in a collection can be registered by Name or by Gameplay Tag. Actors registered dynamically at runtime are automatically unregistered when they are destroyed or unloaded. That gives the system a practical role in scenes where actor availability changes over time and lookup needs to stay current without manual cleanup.
An actor manager is included as well, though it is marked as depreciated. It also handles registration and retrieval of key actors and is noted as a particularly important component for the quest system. Even with the depreciated label, it still occupies a functional place in the project’s overall structure.
The Generic States Save Component addresses persistence. By adding the component to an actor, implementing the relevant interface, and defining the data to save as a string, actor data saving can be set up more quickly. This is a focused utility rather than a broad save framework, but it fits naturally into projects where interaction state, dialogue state, or quest-related actor data needs to persist.
UI Stack Container System and where Project Sunrise fits
The UI Stack Container System uses Common UI to streamline widget management. Widgets can be stacked while other widgets in the stack are hidden, and tagged slots can register specific UI containers to make widget placement easier. The system is also meant to support different UI layouts, with iteration during testing called out as a clear use case.
That makes the package feel suited to teams or solo developers who want a playable gameplay layer in place early, with systems that can be inspected, extended, and swapped through blueprint work. The interaction system handles input and presentation, dialogue adds modular conversation logic, quests provide structured progression, actor collection and registration help world logic stay organized, the save component covers actor data persistence, and the UI stack gives the front end a manageable structure.
In practical terms, Project Sunrise is set up to handle the stage where a project needs connected gameplay systems working together rather than isolated prototypes living on their own.
Preview Images
Protected download
Access this resource
All resources are 100% manually reviewed to eliminate all risks.
