Hi Chris,
I've been working on a quest log system and hit some confusion in how Journals and Documents relate to each other.
Overlap:
Journals and Documents solve similar problems but with different constraints that make it hard to know which to use:
Documents are the right place for pre-authored, localisable, Speech Manager registered content — but they're static, you can't add or modify pages at runtime
Journals support runtime page addition via ActionList — but their content is defined inside Menu elements, meaning content lives in the UI layer rather than in a content/data layer
The "Display Active Document" and "Display Existing Journal" options on Journal elements create a confusing indirect reference chain.
Content Pipeline:
Because Journal pages are authored inside the Menu Manager (if not added via actionlist), content and UI are entangled. There's no clean separation between "what the text says" and "how it's displayed." I write within the menu system rather than in a dedicated content layer.
Documents solve that separation cleanly, but lose runtime flexibility. Journals have runtime flexibility but put content in the wrong place.
Solution:
A unified system where all text content lives in a data layer — like documents are handled currently — separate from menus entirely. Even pages added via actionlist could be collected there for better overview (optional).
Runtime addition and modification of pages is possible via ActionList on any content asset, not just Journals (because the distinction between them is somewhat artificial anyway)
A single menu element type handles display of this content.
I totally get where you are coming from with these systems - from how classic adventure games work. But on a systems level, I think a unified system would be much easier to work with.
It looks like you're new here. If you want to get involved, click one of these buttons!
Comments
Update:
Upon further research, it's not entirely true what I wrote.
If I set a journal to display active document and then run a menu - change state - remove journal page it does indeed remove the page from the document itself.
However, it absolutely obliterated those document pages. They are nowhere to be found after running it once in play mode in editor, even after restarting unity and project.
Is that intended behaviour? Kind of kills the ability to test.
Maybe you can explain a little more how and when these kind of things are saved?
(still think a unified system as described above would be better)